New EEP draft: Pinning operator ^ in patterns

Frans Schneider fchschneider@REDACTED
Thu Jan 14 16:14:36 CET 2021


So many good reasons were given not to introduce the pinning operator 
before in this list.  Very worrying!



On 1/14/21 3:50 PM, A. G. Madi wrote:
> I completely agree with Nicolas. This makes me very nervous.
> On Thu, Jan 14, 2021 at 08:41 Nicolas Martyanoff <khaelin@REDACTED 
> <mailto:khaelin@REDACTED>> wrote:
>     On 2021-01-14 14:13, Richard Carlsson wrote:
>     > The way I planned it is:
>     >   1. Even from the start, pinning will always be allowed,
>     without requiring
>     > any flag to opt in. This does not tell you about existing uses of
>     > already-bound variables, but you can start using pinning right
>     away for
>     > readability and for avoiding bugs when refactoring. The compiler
>     will
>     > always tell you if a pinned variable doesn't exist, so you don't
>     > accidentally accept any value in that position.
>     >   2. You can enable warnings at your own pace in order to start
>     cleaning up
>     > your code.
>     >   3. In a following major release, the warnings will be on by
>     default, but
>     > you can disable them to compile old code.
>     >   4. In a distant future, it might become an error to not use ^
>     to mark
>     > already-bound variables.
>     After reading this thread, I must say this proposal makes me
>     uneasy. One of
>     the things I always liked with Erlang is the simplicity and
>     clarity of its
>     syntax. Matching variables by name is perfectly readable to me,
>     and I never
>     had any problem of the sort refactoring code. Adding a new
>     operator adds
>     noise and transforms something simple (using the same name to
>     refer to the
>     same value) into something cryptic.
>     The fact that you envision a future where not using the operator
>     would signal
>     an error is even more worrisome. I have nothing against improving
>     the core
>     parts of the language (maps were a life changer for example), but
>     this kind of
>     change feels really foreign to the simplicity of the Erlang syntax.
>     And at the risk of sounding too harsh, I would add that while I do
>     not mind the
>     existence of Elixir (quite the opposite, it brought a lot of fresh
>     air to the
>     entire BEAM ecosystem), I would really like Erlang to remain
>     Erlang; in that
>     spirit, I see a new operator to "annotate" a perfectly clear and
>     working
>     syntax as useless.
>     Regards,
>     -- 
>     Nicolas Martyanoff
> <>
>     khaelin@REDACTED <mailto:khaelin@REDACTED>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the erlang-questions mailing list