[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

[Richard O'Keefe]

I should make it clear that my "counter-proposal" is
meant to demonstrate that the possible solution space
relevant to the EEP has NOT BEEN ADEQUATELY EXPLORED YET.
If it were fully worked out, the counter-proposal would
be an EEP itself.

I'm not saying "there is no problem" or "let's never do
anything new" or "Erlang is perfect".  (I've written a
lot of EEPs myself.)

I'm saying something that should be fairly easy to
accept: *this* EEP is nowhere near ready for acceptance.
Frames were an EEP, and we got maps instead (which I am
still miffed about, but everyone else seems to be very
happy).  And we got them a long time after a fairly
detailed Frames design was provided, because the maintainers
wanted one mechanism that solved two different things, not
the one thing that Frames were designed for.

For what it's worth, I had a three-part proposal for
adding something very like assignment to Erlang, starting
with X := e handled by renaming, and proceeding to
assignment of substructures using lenses.  I never got
around to writing it all up, because honestly, there are
just better ways to write Erlang than the ways that would
have been helped with this.  And I can tell you that the
"pinning" operator would not have been useful for this at
all, but on the contrary, a major pain to deal with.
No, an EEP that was never submitted is not a good reason
to reject an EEP that *was*.  All it can be is a reminder
that the space of possible solutions should never be
constrained to "what the cool kids are using".




On Fri, 29 Apr 2022 at 21:48, Loïc Hoguin <essen@REDACTED> wrote:

> On 28/04/2022 14:00, Richard O'Keefe wrote:
> > (A) Fix the original problem.  Erlang had a very
> >      simple scope rule: the scope of a variable is
> >      the *entire* top-level function clause it
> >      occurs in.  Reinstate that rule.
> >      This is a breaking change, so it needs some
> >      sort of -simple_scopes declaration to enable it.
> >      We now have a feature declaration that can be
> >      used for this.
>
> This is the solution I would prefer with regard to solving locality and
> shadowing. But I am well aware that this would not solve the original
> issue, in particular it wouldn't help avoid accidental matching of
> variables that were already bound. What's at the beginning of the
> rationale.
>
> There would still need to be a compiler warning/error (should really be
> an error if not already) about exporting variable from case clauses
> where the variable is not defined in all clauses, though, but that's fine.
>
> > (B) Fix the locality problem.  The right way.
> >      By declaring which variables are *local*,
> >      not which variables are *not* local.
> >      Borrowing some syntax from Prolog (as Erlang
> >      originally got its syntax thence), let D be
> >      a syntactic form made of tuples, lists, and
> >      variables, and C be a pattern or expression.
> >      Then D ^ C means that each of the variables
> >      in D represents a new variable in C, not
> >      provided, visible, or in any way accessible
> >      in C.
>
> This would also be acceptable but I too would like to see what it would
> look like. I fear that it may end up much more complex to the developer
> than the first solution. Also it probably doesn't solve the original
> issue in the rationale.
>
> --
> Loïc Hoguin
> https://ninenines.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20220429/b7e13ee8/attachment.htm>