New EEP draft: Pinning operator ^ in patterns

[Michael P.]

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().
ok
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'.

Maybe:
"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
constant."

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

~M

--

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