Re: New EEP draft: Pinning operator ^ in patterns

Raimo Niskanen <[email protected]>
Newsgroups gmane.comp.lang.erlang.general
Message-ID <[email protected]>
On Fri, Jan 15, 2021 at 07:35:06PM +0100, Olivier Boudeville wrote:
> Le 1/15/21 à 4:35 PM, Raimo Niskanen a écrit :
> > 1) Would the language be a better language with a mandatory pinning operator?
> 
> Hi,
> 
> Thanks Raimo for this interesting EEP. As for me, I could do without 
> pinning. Would such a feature impact the AST?

It is Richard Carlsonn's EEP.

I just find some merit in it and think it gets bashed in an unconstructive
way on lists and pull request.

> 
> On a related "hazardous matching" topic, there is an Erlang "language 
> feature" that could (IMHO) be removed for the best, hopefully with no 
> issue in terms of backward-compatibility: the infamous matching of muted 
> variables. I am a big fan of commenting thanks to a muted variable the 
> intent related to an argument, like in:
> 
>     send_safe(_DefaultTimeout=1000, _AttemptCount=5, ...),
> 
> ...but of course such bindings will collide with any other, potentially 
> unrelated _DefaultTimeout or _AttemptCount bindings in the same scope, 
> resulting in "surprise-matches" that could be spared to the unwary 
> developer.
> 
> Couldn't we stop matching these muted variables, knowing that their 
> management is already special-cased in some contexts? (for example they 
> do not trigger unused warnings; "_" is never bound either). No sane 
> existing code should rely on this kind of match anyway, isn't it? Or is 
> there a use-case I overlooked? If the semantics of muting is "don't care 
> about the value", isn't it more surprising that they match rather than 
> they do not?

I am sure that you are aware of the fact that it is only the _ variable
that is anonymous and different for every occurence.

The _Variables with a leading _ are normal variables, but a compiler
warning for not using them is muted.

There is a use case I have seen that you may have overlooked:

    _X = foo(),
    ?debug_print(_X),

where depending on a compile time definition ?debug_print/1 may not use _X
at all.  Anyway, it is mainly some kinds of debug code, also simply
commenting out an io:format, but being to lazy to remove a variable.

Jose Valim has suggested a warning for repeated occurences of underscored
variables, since as you (and he) say(s), it is almost always accidental.

It may be a win to loose the debug use case above.


> 
> Best regards,
> 
> Olivier.
> 
> -- 
> 
> Olivier Boudeville

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.