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

[Fred Dushin]

So I am a little confused.  Reading the EEP,

f(X, Y) ->
    case X of
        {a, Y} -> ok;
        _ -> error
    end.

means the same as

f(X, Y) ->
    case X of
        {a, ^Y} -> ok;
        _ -> error
    end.

So it adds nothing semantically to the language.

The more compelling example is binding a clause head in a local function definition to a previously bound variable.  From the EEP:

f(X, Y) ->
    F = fun ({a, ^Y})  -> {ok, Y};
            (_) -> error
        end,
    F(X).

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).

So as far as I can see, the proposal is at best proposing syntactic sugar over what can already be accomplished in the language.  Current Erlang might be more verbose (by character count), but to say it is more or less clear is in the eye of the beholder, certainly.

I think the real question is whether the language should admit two ways of accomplishing the same thing (and by that, I mean compiling to effectively the same BEAM ASM), and that is really up to the language maintainers.

If you want my personal opinion (I know, you didn't ask), I lean on the side of "Less is more", when it comes to language features.  Having to read Scala in my day job, I can't think of a programming language that more violates the principle of linguistic parsimony -- it even puts C++ to the test!

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 (?)

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.


Also, kind of a stupid question, but wouldn't

f(X, Y) ->
    case X of
        {a, Y} -> ok;
        _ -> error
    end.

be more clearly written:

f({a, Y}, Y) -> ok;
f(_, _) -> error.

I would never write the former, if I had the option to write the latter, but that just may be my personal preference.

-Fred

> On Apr 21, 2022, at 8:32 AM, Leonard Boyce <leonard.boyce@REDACTED> wrote:
> 
>> 
>> EEP-0055 (https://github.com/erlang/eep/blob/master/eeps/eep-0055.md) was submitted on
>> 21-Dec-2020.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20220427/fac38503/attachment.htm>