<html><head></head><body>No current code will be broken if an infix 'in' operator is parsed based on context as it's not currently used.<br>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.<br><br>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.<br><br>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.<br><br>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?<br><br><br><div class="gmail_quote">On 27 March 2019 06:37:43 GMT+11:00, "Dániel Szoboszlay" <dszoboszlay@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Daniel<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Mar 2019 at 19:25 Eckard Brauer <<a href="mailto:eckard.brauer@gmx.de">eckard.brauer@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Tue, 26 Mar 2019 11:15:28 -0400<br>
schrieb Fred Hebert <<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>>:<br>
<br>
> On Tue, Mar 26, 2019 at 10:51 AM Florent Gallaire<br>
> <<a href="mailto:fgallaire@gmail.com" target="_blank">fgallaire@gmail.com</a>> wrote:<br>
> <br>
> > It's also a good opportunity to make Erlang more modern with a sexy<br>
> > syntactic sugar...<br>
> ><br>
> ><br>
> <br>
> this should be done very carefully. For example, adding the 'in'<br>
> keyword for 'X in [A,B,C]' syntax will break all existing code out<br>
> there that uses the word 'in' for a function, including the<br>
> `queue:in/2` function call in the standard library. That could ripple<br>
> into inconsiderate breakage in the whole ecosystem.<br>
<br>
I don't really prefer lists_member/2 or is_member/2 over 'X in [A,B,C]'<br>
or the other way, but could you please enlight me (rather erlang<br>
beginner) about where/why this would break existing code? If we talk<br>
about a list as the second/right side arg of 'in', I could think of<br>
either having an opening bracket '[' or a variable bound to that list<br>
("when X in List") after the keyword when to be used as a guard, or of<br>
'(' when to be used as the abovementioned function call. So for me,<br>
that looks rather simple, but as already written, I'd like to further<br>
improve knowledge.<br>
<br>
Thanks in advance<br>
Eckard<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div></div>
</blockquote></div><br>-- <br>Kind regards,<br>Dmitry Belyaev</body></html>