New EEP draft: Pinning operator ^ in patterns

[Richard Carlsson]

Den tors 28 jan. 2021 kl 15:38 skrev Coconut <c0c0nut@REDACTED>:

> > The question is where we can go. If we don't find ways to improve - in a
> fairly big way - we will keep losing traction.
>
> Are you not making the assumption here that this pinning operator is an
> improvement that Erlang desperately needs (e.g. to not die)?
>

It's not desperately needed on its own. But I am making the assumption that
without a change like it (such as moving away completely from already-bound
variables in patterns, using guards only instead), I don't see many ways to
changing other scoping rules either, in either direction, in a way that
preserves compatibility. That in turn limits a lot of other things.

You are right, Erlang has to find ways to improve, but is the pinning
> operator that, an improvement?
>

That is the question that I want to focus on. I think I have been clear
through the examples that I have shown that I do think it is an improvement
on its own. In my opinion it is less long-winded than using guards only,
and at the same time stands out quite well when reading the code, showing
the programmer's intent. Some people might not agree with this judgement,
and that's fine. Any actual decision has to take a lot of people into
account.

I agree with responses such as (this particular one is by zxq9) this:
>
> > Changes that move directly against one of the most basic core concepts
> of the language are not only a disservice to existing codebases written
> with those core concepts in mind, but also leaves homeless users who are
> attracted to Erlang specifically because of those core concepts.
>

I would argue that implicitly using an already-bound variable in a pattern
is not a core feature, not by far compared to other core features. As I
showed, it occurs in most every module, but on a small percentage of lines.
It's rare enough that it could be feasibly deprecated and dropped from the
language instead - some people on the list expressed a preference for this
variant - and even those with big codebases could handle such a transition
pretty easily. If it wasn't there, most of Erlang would remain the same.
Many users wouldn't even miss it. I would prefer to keep it because it
makes some kinds of code neater, but I would like to make it explicit so
you see that it's there.

        /Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210128/ce985bde/attachment.htm>