Re: New EEP draft: Pinning operator ^ in patterns

On 18/01/2021 10:59, Raimo Niskanen wrote:
> 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.

As long as it's optional. It's the kind of scenario where I definitely 
want to avoid using _X variables for normal builds, but want to keep 
using _X variables during test builds for debug purposes. In that case 
it's more a convenience than anything admittedly.

-- 
Loïc Hoguin
https://ninenines.eu