[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055
Fri Apr 29 13:44:58 CEST 2022
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions