New EEP draft: Pinning operator ^ in patterns

empro2@REDACTED empro2@REDACTED
Mon Jan 18 13:08:54 CET 2021


On Fri, 15 Jan 2021 16:35:57 +0100
Raimo Niskanen <raimo+erlang-questions@REDACTED> wrote:

> 1) Would the language be a better language with a mandatory pinning operator?
>
> 2) If so is there a migration path worth the trouble?
>
> So far I think the discussion has been centered around 2),
> before talking about 1).

Exactly! When this appeared years ago (feels like it, calendar calls it "days"), my very first association was a telegram line from _Blackadder goes forth_:

    > "Please please please stop"

Not so much as an immediate SIGABRT, but more as a SIGSTOP with a chance for a SIGCONT.


> And I want to get clarity about exactly why so many developers are worried
> about this particular proposed change, and therefore try to look thoroughly
> at the arguments.

I have written up and deleted what feels like three books on this. I usually take a second look at my drivel from the fresh context of a new day, by which time there are new messages and statements to consider. So I went into a delete-rearrange-add loop.

Some of what remains can be read between the lines of others, or might simply be worth mentioning more explicitly ... or again ... and, of course:

    > "I may be wrong / I may be right" ...


 Cons
------

C1 "Never change a running system."

C2 "The more people contribute to a project, the more its result approaches mediocrity."

C3 "I may be wrong / I may be right / Money short / And time is tight"

P: Well, right at the bottom it says "The implementation can be found ...".
C? What about hidden expenses? Maintenance? Consequential "enhancements"?

C4 "If in doubt -- leave it out." (or KISS (not those!))
Documentation is to a programming language as comments are to code: the less required, the better.
P: With it there would be less to explain.
C? EEP 55 and this thread etc. do not make this exactly obvious ...
P: I will show you ....
C? Go ahead!

C5 "Explicit is better than implicit" I had this pinned (no pun intended) to the wall once, but then replace a name and a comparison with a fly-dropping? We get pattern variables dumped into scope when accident- or intentionally bound in every clause of ... well, except funs. Are we going to annotate variables that get bound in every clause? or the others?

C6 Shadowing cannot argue in favor of explicitness? A function should do only one job and do that well. Being part of a function a fun cannot do the same job the surrounding function (clause) does. Serving a different purpose its parameters must serve different purposes and thus deserve different names, be it merely `Count2` or `Subcount` or at least `Y2`, no?
P: These are merely examples.
C? But what does it mean that they are that way?

C7 The differences between `catch` and `catch, and `after` and `after` must be "deduced" from context, or is someone already feeding the flies? More deducing of meaning from context might be better than preparing code for a compiler that does not care about what value a variable is bound to. Is this somehow like that manifestly and explicitly typed variables (and hungarian notation) debate? All this type info hiding, at least distracting from what is really meant, of course, preventing some errors, but ... (Erlang `-spec`s are even less distracting than Lisp annotations :-)

C8 Shoving chunks of code around in an endless script editing manner is better solved by education.

C9 Shoving such chunks containing "pinned" and "unpinned" variables around is an additional source of error and work, keeping, removing and adding "pinnings" (and all that without looking at the context, because that was the original reason ... ;-)

C10 Prevent "Then `^^Y` must refer to the scope around the outer scope, similar to git."


 Pros
------

P1 "Without annotations, you cannot read and understand a pattern [...]"
C: In the last 30 years it must have been, at least sufficiently, possible.

P2 "or adds what they thought was a new variable further up."
C: Having some uncontrollably changing "up there" prevents explicitness "down below" as one cannot be sure of what to be explicit about.

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

C: Looks a bit like a desire for

    Zuul = here,
    No = fun Zuul(Zuul, <<Zuul:Zuul>>) -> Zuul end.

and then gonna call for additional fly-droppings to "make intent explicit" (and this possible). Contradiction: shadowing variables <+> arguing with explicitness?
Why not?

    job_1(X, Y) ->
        Job_2 = fun ({a, C, R}) when C =:= Y -> {ok, R};
                (_) -> error
            end,
        Job_2(X).

Not as minimal, but who wanted to be explicit? And I would call some fly-dropping instead of a name and a comparison not exactly explicit.

P4 ... there might be something if the "up there ... down below" cannot be solved by education because there are problems that need to be solved in an endless script manner ...
C: For example ...?!

P5 ... something about those assignment, comparison and assertion aspects of matching.
C? I have never really perceived it as being being (only) one of these, it is somehow more a kind of aggregation of these? with synergies? Would not even call `A = 1.` an assignment, or only in explaining some OO-cultist with a more imperative and hidden procedural background:

    > EB: If I have two beans, and then I add two more beans, what do I have?
    > B: Some beans.
    > EB: Yes! And no!

    [Replace the beans with matching and assigning.]

I must admit, though, that I do not really know what I am talking about, or what it really means below this surface. TeX `\def` and `\let` and LaTeX `\newcommand` and `\renewcommand` also feel like "Yes! And no!", but

    > "That's my impression / It's an expression / And a suggestion"


And now for something completely different:
-------------------------------------------

> A pinning operator can not be added to Prolog

*cannot? *grin*


	~Michael

--
Curiosity killed the cat -
by simply using up its time.







More information about the erlang-questions mailing list