New EEP draft: Pinning operator ^ in patterns

Michael P. empro2@REDACTED
Tue Jan 26 21:10:06 CET 2021


On Tue, 26 Jan 2021 12:05:59 +0100
Ingela Andin <ingela.andin@REDACTED> wrote:

> The pinning operator, or actually annotation,

Names are so important!

> and teacher. When teaching Erlang I would tell my students that to program
> Erlang/OTP they need to change their mindset from when programming in
> imperative or object oriented languages. There are some things that are

And keep it changed. The trouble with "multi-paradigm" languages: one sets out FP, requires a library that is OO, and the "little things" are uctured. Always alternating between three different ways of organising your solution of the domain problem. And three bags full of syntax and semantics ... on top of "how do these libraries work together?"

> and single assignment, recursion being a very common way to solve the
> problem and how you think about concurrency.

Funny! wrote this just a few hours ago:
Take my word for it!

There is no assignment: you do not assign to constants, you define them -- done!

They should be called "symbols", though, because in a function head they can be quite variable -- but only from one call to another. Here they can appropriately and distinctly be addressed as "variables". Variables parameterise the associated code (guard seq. and body) like any other function parameter (e. g. closures, os:getenv/N), but variables can change between calls. Both parameters and variables are symbols. (Together with function atoms and macroes(?) they could make up the useless(?) group of "identifiers"? I am really rooftopping the brink of my knowledge.)

There are no "invariable variables", that is why that heading makes us smile.

And oh, yes, recursion, or: no loops! You must have looked into many an open mouth ;-)

(Well, apart, from list comprehension, Erlangs `loop` macro ...)

> programmers solve problems the "Erlang way".  Also this is not counting all
> the matches done in function clauses where the annotation makes no sense
> (and hence is not included in the "pinning").  So with pinning we will have
> two ways of matching depending on where we match.

I feared that annotated boundies in patterns in (module level) function heads and bodies might "deref" into the calling scope ...

> Now the EEP proposal does not allow rebinding of variables, but let's face
> it that would be the next step. Especially  when that is part of why Elixir

I say, I say, I say (look for the crying walrus operator `:,=` ...)

> needs to have a "pinning operator". And it is argued that we should have
> the ^ to resemble Elixir. Now I am not saying we should allow variable

Keep languages distinct and apart, just like programming paradigms. The brain is completely associative, will connect it all and make "context switching" hard.

> I think it is human to consider too little of the context and alas the
> compiler will never be able to catch all the times, we also have to rely on

The annotation would only say that something is bound, not why or whether it should be at all. The work on the "Erlang semantics" level will distract from the "domain semantics" level.



Car and cider give me a pleasant mediterranean
feeling, whereas cdr makes me shudder.

More information about the erlang-questions mailing list