Re: New EEP draft: Pinning operator ^ in patterns
Nicolas Martyanoff <[email protected]>
| Newsgroups | gmane.comp.lang.erlang.general,gmane.comp.lang.erlang.eeps |
|---|---|
| Message-ID | <YABV8Vxx1WMfj96m@valhala> |
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 http://snowsyn.net [email protected]