New EEP draft: Pinning operator ^ in patterns

Michael P. empro2@REDACTED
Thu Jan 28 20:22:37 CET 2021

On Thu, 28 Jan 2021 16:18:06 +0100
Raimo Niskanen <raimo+erlang-questions@REDACTED> wrote:

> On Thu, Jan 28, 2021 at 03:35:32PM +0100, Michael P. wrote:
> > On Wed, 27 Jan 2021 23:04:54 +0100
> > Raimo Niskanen <raimo+erlang-questions@REDACTED> wrote:
> >
> > > So have no fear, the pinning operator would not take away any feature from
> > > Erlang.  Hopefully it would give clarification to newcomers; when I first
> >
> > Sorry, but yes it would: its simplicity!
> But it can be argued that in this case the simplicity is only apparent,
> since the simplicity hides two fundamentally different cases.
> So it might in fact be too simplistic now.

Yes, right, and I still find it hard to see
which is / would be simpler.

I simply inverted the certainty of your statement and also
implied two things:
disallowing boundies from patterns as a simpler solution;
and, so far, too much neglected consequences, like
growth, overlapping with more general solutions (eval, var, ref),
leaving only `**` for `math:pow(,)`, discouraging search for
meaningful names ("that mark is enough").

> > > learned Erlang I missed some way to see the difference between binding a
> > > variable in a pattern and using an already bound variable.
> >
> > Is that not only the case with the match operator?
> Sorry.  Please explain.

`?? = 7, ..., {G, S} = {5, 7} %% ==> ??`

That is what intrigued me: is G bound? S? both?
If one was bound there is no obvious difference
to the unboundie, I do not like such.

But this is all about match-operator patterns --
they are special and not even mentioned in the proposal.

In all(?) other patterns the compiler

> > Do not all other patterns intoduce a new scope?
> Binding a variable is the start of the scope for that variable.

Do you mean extent? (Do I know what I am talking about? :-))

13> f().
14> {A, A} = {1, 2}.
** exception error: no match of right hand side value {1,2}
15> A.
* 1: variable 'A' is unbound

A was bound, but not in the scope of 13 (or if so,
it has been unbound, to the same result).

> The scope ends where the function clause ends.
> Or the fun() clause.

A successful matching seems to export bindings to
the surrounding scope, a bit like the "sneak export"
in `case` patterns.

Speaking of which: only by analysising _all_ patterns of
a `case`, can such exports be recognised. Will the next
EEP suggest annotating these?

> > And friend compiler already warns about any attempt
> > at closure therein?
> Are you talking about fun() argument shadowing here?
> What about it?

Argument? You mean the subset of function parameters that
get bound to arguments in a call?
I call these function variables, to distinguish from other
function parameters that get bound in a different way
(getenv(), closures).
(arguments = terms = values = operands; function = operator;
e. g. 1 + 2, math:log(7))

> > The Erlang doc says:
> >
> > a) "A pattern has the same structure as a term but
> >     can contain unbound variables."
>       Bound variables in a pattern may/should be annotated
>       with a preceeding ^.
> I tried to complete a) above, how does that look?

Painful :-) I would really like to pretend for a while that there
was no solution (and if so `~`, not `^`, or `ref`, or even `var`
or `const` for the unboundies :-)
and concentrate on gripping the problem and finding alternatives.

Without alternatives the weight of the arguments for and against,
say `^`, cannot be assessed.

As mentioned above a term is a value; a boundie is no value but
an expression; a term cannot contain an expression but a pattern
can. It says "same structure" but anyone not knowing what is meant
will understand 'is term'.

"A pattern is like any term literal, but can contain both unbound
variables and variables bound in its lexical scope.

The only expressions allowed in a pattern are bound variables and
arithmetic expressions that can be compile-time evaluated to a

Blah ... I am really rooftopping the brink of my abilities here.

> > I would not want to add any explanation of a syntactical
> > annotation to that. Not even after a cleanup, as this shows
> > that it is already complicated enough.
> ...or that it should be explained better...

OC, it should. I meant that it is evidently already so complicated,
that one attempt of explanation has already failed. :-)

> > I am working on the examples but for now: does it not simply
> > _hide_ a need to rephrase to explicitness?
> Awaiting examples...

Most of my remaining notes (about a handful) concern examples.
RC was so kind to provide plenty :-)

> > By the way: Is it an operator in Elixr? If not, I would quickly
> > retreat two steps from anything and anyone having to do with Elixir.
> That a similar operator exists in Elixir is not in itself a valid argument
> against introducing this operator in Erlang.

I mean that people having to do with language and calling s/th
that is no operator "operator" is a bit scary.

Here is another alternative:
is there an Erlang operator (function)
that yields the term bound to a variable? If so, how about allowing
that in patterns (next to, or instead of boundies)?



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

More information about the erlang-questions mailing list