[erlang-questions] Guards syntax for multiple values

[Dmitry Belyaev]

No current code will be broken if an infix 'in' operator is parsed based on context  as it's not currently used.
If an auto-impotred function 'erlang:is_member' is introduced, the code previously using locally defined function 'is_member' will be broken. If the bif is not auto-imported its usage in guards will be very confusing.

All these proposed changes - a new operator, or a new function - to me look as too small changes, not really solving the main problem - absence of convenient and accepted way to metaprogramming. Just have a look how many proposals to Elixir are rejected as almost all of them are implementable using macros.

It reminds me all those libraries implementing different improvements to the language like erlando, gin and many others that don't become used much only because parse transforms are not accepted solution to the Erlang language problems.

Maybe we should shift our attention from a list of newly added bifs and those suggested to be added to a more generic way to solve these and other similar problems once and for all?


On 27 March 2019 06:37:43 GMT+11:00, "Dániel Szoboszlay" <dszoboszlay@REDACTED> wrote:
>You are right that a parser could easily distinguish "X in Y" from
>"M:in(...)" or even "fun M:in/N" based on the context. The problem, as
>I
>see it, is that "X in Y" introduced a new infix operator to the
>language,
>while "is_member(X, Y)" does not, it is syntactically just an ordinary
>function call.
>
>The first problem with introducing a new operator is that there are
>some
>conventions for operators in Erlang. Like every alphabetic operator is
>currently a reserved word. So we either break this convention with
>"in", or
>we make "in" a reserved word that would break all the existing
>"M:in(...)"
>use cases. I like neither of these options.
>
>The second problem I see with a new operator is that it would require
>an
>update of every tool that parses Erlang code. An Erlang parser is very
>likely to have a hard-coded list of operators (together with e.g. the
>precedence order of them), and wouldn't just try to parse any atom as a
>potential infix operator. On the other hand, a parser may have a
>hard-coded
>list of BIF-s that are allowed in a guard, but that's not likely. Most
>probably it would just accept any function call in a guard position, so
>going with "is_member/2" or "lists_member/2" would not break a typical
>parser.
>
>Cheers,
>Daniel
>
>On Tue, 26 Mar 2019 at 19:25 Eckard Brauer <eckard.brauer@REDACTED>
>wrote:
>
>> Am Tue, 26 Mar 2019 11:15:28 -0400
>> schrieb Fred Hebert <mononcqc@REDACTED>:
>>
>> > On Tue, Mar 26, 2019 at 10:51 AM Florent Gallaire
>> > <fgallaire@REDACTED> wrote:
>> >
>> > > It's also a good opportunity to make Erlang more modern with a
>sexy
>> > > syntactic sugar...
>> > >
>> > >
>> >
>> > this should be done very carefully. For example, adding the 'in'
>> > keyword for 'X in [A,B,C]' syntax will break all existing code out
>> > there that uses the word 'in' for a function, including the
>> > `queue:in/2` function call in the standard library. That could
>ripple
>> > into inconsiderate breakage in the whole ecosystem.
>>
>> I don't really prefer lists_member/2 or is_member/2 over 'X in
>[A,B,C]'
>> or the other way, but could you please enlight me (rather erlang
>> beginner) about where/why this would break existing code? If we talk
>> about a list as the second/right side arg of 'in', I could think of
>> either having an opening bracket '[' or a variable bound to that list
>> ("when X in List") after the keyword when to be used as a guard, or
>of
>> '(' when to be used as the abovementioned function call. So for me,
>> that looks rather simple, but as already written, I'd like to further
>> improve knowledge.
>>
>> Thanks in advance
>> Eckard
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>

-- 
Kind regards,
Dmitry Belyaev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190327/48647330/attachment.htm>