New EEP draft: Pinning operator ^ in patterns

[Loïc Hoguin]

On 20/01/2021 17:27, Raimo Niskanen wrote:
> On Wed, Jan 20, 2021 at 04:22:26PM +0100, Kostis Sagonas wrote:
>> On 1/20/21 3:42 PM, Raimo Niskanen wrote:
>>> I have vague feeling that this has been asked,
>>> but since I can not find it:
>>>
>>> How is nested fun()s handled?
>>>
>>> foo(Y) ->
>>>       F = fun (X) ->
>>>            Y = X + ^Y,
>>>            FF = fun (Z) ->
>>>                     Z + ^Y
>>>                 end,
>>>            FF(Y)
>>>           end,
>>>       F(Y).
>>>
>>> Does the innermost Z + ^Y access the outermost Y from foo(Y), or the Y
>>> bound in F/1 i.e Y = X + ^Y?
>>>
>>> Is there a way to choose which of the outer Y:s to refer to from within FF/1?
>>
>> Raimo: Your question about nested funs is a good one.
>>
>> However, I thought that ^ was meant to be used in *patterns* (this is
>> even in the subject of this sad thread), and I do not see ^ being used
>> in patterns in your example.
>>
>> Am I missing anything?
> 
> Nope.  I missed that.  Felt like something one might want to do.
> 
> Let's see if I manage to use patterns instead:
> 
> 1: foo(Y) ->
> 2:      F = fun (Y) ->
> 3:           FF = fun (Y) ->
> 4:                    ^Y = Y - 1
> 5:                end,
> 6:           FF(Y + 1)
> 7:          end,
> 8:      F(Y + 1).
> 
> I guess that would produce warnings for shadowing on line 2 and 3.
> I guess that ^Y on line 4 refers to the Y bound on line 2.
> I guess that warn_unpinned_vars would not produce any warnings.
> Can I match against the Y bound on line 1 from within FF/1?

I'll spare myself the headache of trying to make sense of such a 
snippet. However I will say that whatever new thing gets into the Erlang 
language should not introduce more confusion around scoping or shadowing.

I'm only OK with the same variable names being used in different scopes 
(real or imaginary) if they refer to the same value. For example I would 
be OK if Erlang allowed this:

   Config = case get_config() of
       undefined -> default_config();
       Config -> Config
   end

But I would not be OK if Erlang allowed this:

   Config = case get_config() of
       undefined -> default_config();
       Config -> [{extra, value}|Config]
   end

We already have scoping confusion with funs and lists comprehensions, we 
should not add more. Better yet if this shadowing becomes completely 
forbidden. Then there's no confusion to be had about which variable ^ 
refers to.

Cheers,

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