New EEP draft: Pinning operator ^ in patterns

[Eckard Brauer]

Am Mon, 18 Jan 2021 12:19:07 +0100
schrieb Loïc Hoguin <essen@REDACTED>:

> > Being able to write "A = 5, A = inc(4)." is what makes the Erlang
> > language the best I've used in my opinion.  
> > 
> > Could you please explain the semantics of this statement?
> > It is not obvious for me as a beginner.
> > 
> > Why is such a statement so useful for you?  
> 
> "A = 5,"
> 
> means the variable A becomes bound and has the value 5.
> 
> Followed by
> 
> "A = inc(4),"
> 
> where it is implied that "inc(X) -> X + 1."
> 
> Because A is already bound, this becomes a match. The match will only 
> succeed if the value returned by the inc/1 function is the same as
> the value already bound to A.
> 
> If the inc/1 function had a bug and somehow returned the wrong value, 
> the match will fail.
> 
> It's not so much about usefulness and more about a thought process.
> All instances of A must have the same value as the first time it was 
> "matched" otherwise the program doesn't work. In my mind, there is no 
> real distinction between binding and matching, it's all just
> matching. The first match just happens to dictate what the value must
> be subsequently. Having to annotate explicitly the matching of bound 
> variables would be a pretty big change to that thought process, so
> the rewards would have to be really worth it.

The 1st "match" (against a before unbound variable) has in fact the
effect of binding, constraining the variable to the given value (5 in
the above case - there are different sorts of constraints in other
languages, see e.g. Prolog constraint handling rules). All following
matches in the validity range for that variable are real matches, which
could either succeed or fail.

While the reuse of a variable inside a closure (as e.g. in C or Python
or...) seems beneficial, it's not in all cases. Therefor most (all?)
functional languages avoid mutable variables to avoid side effects (I
wouldn't mix the understang of variables behviours in different
languages, it's simply different concepts).

That in turn is IMHO a central aspect of a language, and changing that
will immediately need a change in how developers think their
algorithms, both in future and back the history. May all developers be
able to restart thinking a new way, the whole history is left behind
and either needs to be first identified and 2nd marked as being "the old
fashion" or to be reworked.

That's the reason I treat variable annotation (the "pinning operator")
as somehow orthogonal to my understanding of Erlang's (current)
features and, should it arise, an important and so far dangerous change
of the language.

But maybe I'm simply wrong...

E.

-- 
Wir haften nicht für die korrekte Funktion der in dieser eMail
enthaltenen Viren. We are not liable for correct function of the
viruses in this email! :)