<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>