# New EEP draft: Pinning operator ^ in patterns

Loïc Hoguin essen@REDACTED
Wed Jan 20 17:40:49 CET 2021

```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?
>>
>>
>> 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