[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

[Richard O'Keefe]

I can't recall everything I said against this EEP,
but there are two issues I can think of right now,
and a better alternative.
(A) Inconsistency.
    Suppose a variable occurs multiple times
    in a single pattern.  What does it mean if
    it is "pinned" in some of those occurrences
    but not others?  Are there two different
    variables?
    Suppose a construct has multiple clauses,
    and a variable is "pinned" in some of those
    clauses but not others.  Are there two
    different variables?
(2) There are other problems with scope that we
    want to address, but "pinning" does nothing
    for them.  (The classic one is people
    expecting variables to be local to a 'case'
    but leaking out.)

The counter-proposal is quite simple.
(A) Fix the original problem.  Erlang had a very
    simple scope rule: the scope of a variable is
    the *entire* top-level function clause it
    occurs in.  Reinstate that rule.
    This is a breaking change, so it needs some
    sort of -simple_scopes declaration to enable it.
    We now have a feature declaration that can be
    used for this.

(B) Fix the locality problem.  The right way.
    By declaring which variables are *local*,
    not which variables are *not* local.
    Borrowing some syntax from Prolog (as Erlang
    originally got its syntax thence), let D be
    a syntactic form made of tuples, lists, and
    variables, and C be a pattern or expression.
    Then D ^ C means that each of the variables
    in D represents a new variable in C, not
    provided, visible, or in any way accessible
    in C.

With this approach, local scope is available for
*every* construct.  With the scope marker being
located at the *beginning* of a construct, instead
of being buried possibly deeply inside, it should
be easier to read.




On Thu, 28 Apr 2022 at 14:52, Dmytro Lytovchenko <
dmytro.lytovchenko@REDACTED> wrote:

> Would it provide a solution to just assume that the variable shadowing is
> never wanted?
>
> What if code like:
>     f(X) -> fun(X) -> X end.
>     g(Y) -> case h() of Y -> %code% end.
>
> 1. Could create an error due to X being shadowed.
> 2. Could compile with inner X shadowed but a guard is added by the Erlang
> compiler, comparing inner to the outer:
>     f(X) -> fun(X2) when X2 =:= X -> X2 end.
>     g(Y) -> case h() of Y2 when Y2 =:= Y -> %code% end.
> 3. Current behaviour: Inner X is shadowed and is an entirely new variable
> (leads to naming and scoping confusion)
>
> Solution 2 does not introduce new syntax and matches expectations for many
> developers. The compiler fixes the confusion during the compile time. Also
> should not break the existing code.
>
> On Wed, 27 Apr 2022 at 21:11, Attila Rajmund Nohl <attila.r.nohl@REDACTED>
> wrote:
>
>> Fred Dushin <fred@REDACTED> ezt írta (időpont: 2022. ápr. 27., Sze,
>> 15:14):
>> >
>> [...]
>> > But as noted later in the EEP, this can be written as
>> >
>> > f(X, Y) ->
>> >     F = fun ({a, Z}) when Z =:= Y  -> {ok, Y};
>> >             (_) -> error
>> >         end,
>> >     F(X).
>> [...]
>> > And not to be too critical, but I am having a hard time understanding
>> parts of the Rationale section.  The author(s) suggest(s) that in current
>> Erlang temporary variables are needed to achieve the same as the proposed
>> glyph, but then provide an example that uses a guard (as above) but doesn't
>> use a temporary variable, after all (?)
>>
>> Z is the temporary variable in the above example.
>>
>> > I am not sure what the problem is with temporary variables.  The
>> compiler has registers at its disposal, so I don't think it's a performance
>> argument, but more an issue of readability, which again, I think is a
>> purely aesthetic question, and has no bearing on the features of the
>> language, per se.  In other words, the proposal is not suggesting anything
>> that cannot already be achieved in current Erlang, with effectively the
>> same compiled BEAM ASM.
>>
>> Naming is hard, and if you have to come up with two meaningful
>> variable names instead of one, it's even harder. This leads to code
>> like this:
>>
>>      F = fun ({a, TmpMeaningfulName}) when TmpMeaningfulName =:=
>> MeaningfulName  -> {ok, MeaningfulName};
>>
>> The current solution in the language easily leads to too long lines or
>> overly verbose code.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20220429/21c21a80/attachment.htm>