<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">"If there is no reason the compiler could not do it [using existing syntax]</div><div class="gmail_default" style="font-family:monospace,monospace"> we *really* need new syntax."</div><div class="gmail_default" style="font-family:monospace,monospace">That does not make sense.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">And I shall keep on repeating</div><div class="gmail_default" style="font-family:monospace,monospace">* this is the code of code which should never be written by hand</div><div class="gmail_default" style="font-family:monospace,monospace">* when it is generated by a simple script, who cares what the</div><div class="gmail_default" style="font-family:monospace,monospace"> generated code looks like?</div><div class="gmail_default" style="font-family:monospace,monospace">With frequent mutterings of</div><div class="gmail_default" style="font-family:monospace,monospace">* with this number of cases, no matter HOW you write it, the safe money</div><div class="gmail_default" style="font-family:monospace,monospace"> says "it's wrong". And it arguably is, so</div><div class="gmail_default" style="font-family:monospace,monospace">* what code like this needs above all is documentation.</div><div class="gmail_default" style="font-family:monospace,monospace">When you are dealing with Unicode characters, the chances are excellent</div><div class="gmail_default" style="font-family:monospace,monospace">that you need to represent some characters your available fonts cannot</div><div class="gmail_default" style="font-family:monospace,monospace">display, and if yours can, mine that I am reading your code with</div><div class="gmail_default" style="font-family:monospace,monospace">probably cannot.</div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">is_fraction(($½ | $â…“ | $â…” | $¼ | $¾ |</span><span style="font-family:Arial,Helvetica,sans-serif"> $â…• | $â…– | $â…— | $â…˜ | $â…™ | $â…š | $â… |</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">          $â…› | $â…œ | $â… | $â…ž | $â…‘ | $â…’ )) -> true;</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">is_fraction(_) -> false.</span><br style="font-family:Arial,Helvetica,sans-serif"></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">doesn't look too bad, does it? No new operator. No new reserved</div><div class="gmail_default" style="font-family:monospace,monospace">word. It _is_ new syntax, but it is strictly more general than the</div><div class="gmail_default" style="font-family:monospace,monospace">rather ugly 'in' special case.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Mar 2019 at 01:38, Florent Gallaire <<a href="mailto:fgallaire@gmail.com">fgallaire@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Richard,<br>
<br>
Thanks for your answer.<br>
<br>
> lists:member(X, [X1,X2,X3,X4]) answers true or false.<br>
> There is no fundamental reason that the compiler could not<br>
> expand that in-line to (X =:= X1 orselse ... orelse X =:= X4)<br>
> when the shape of the list is known. So we *definitely* need<br>
> no new syntax.<br>
<br>
So if there's no reason the compiler could not do it, we *really*<br>
should have a new syntax.<br>
<br>
> We really need an actual concrete example of real code to discuss.<br>
<br>
The developed version of the is_fraction/1 function:<br>
<br>
is_fraction($½) -> true;<br>
is_fraction($â…“) -> true;<br>
is_fraction($â…”) -> true;<br>
is_fraction($¼) -> true;<br>
is_fraction($¾) -> true;<br>
is_fraction($â…•) -> true;<br>
is_fraction($â…–) -> true;<br>
is_fraction($â…—) -> true;<br>
is_fraction($â…˜) -> true;<br>
is_fraction($â…™) -> true;<br>
is_fraction($â…š) -> true;<br>
is_fraction($â…) -> true;<br>
is_fraction($â…›) -> true;<br>
is_fraction($⅜) -> true;<br>
is_fraction($â…) -> true;<br>
is_fraction($â…ž) -> true;<br>
is_fraction($â…‘) -> true;<br>
is_fraction($â…’) -> true;<br>
is_fraction(_) -> false.<br>
<br>
The awful actual "with a guard" version:<br>
<br>
is_fraction(X) when X =:= $½; X =:= $⅓; X =:= $⅔; X =:= $¼; X =:= $¾;<br>
X =:= $â…•; X =:= $â…–; X =:= $â…—; X =:= $â…˜; X =:= $â…™; X =:= $â…š; X =:= $â…;<br>
X =:= $â…›; X =:= $â…œ; X =:= $â…; X =:= $â…ž; X =:= $â…‘; X =:= $â…’ -> true;<br>
is_fraction(_) -> false.<br>
<br>
The pretty, easy and obviously needed "with in list syntactic sugar" version :<br>
<br>
is_fraction(X) when X in "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚â…⅛⅜â…â…žâ…‘â…’" -> true;<br>
is_fraction(_) -> false.<br>
<br>
It clearly speaks for itself.<br>
<br>
Cheers.<br>
<br>
> On Mon, 25 Mar 2019 at 18:12, Florent Gallaire <<a href="mailto:fgallaire@gmail.com" target="_blank">fgallaire@gmail.com</a>> wrote:<br>
>><br>
>> Frank thanks for your answer.<br>
>><br>
>> > You’re probably new to Erlang.<br>
>><br>
>> Yes, but...<br>
>><br>
>> > You can achieve the same with parse_transform:<br>
>> > <a href="https://github.com/mad-cocktail/gin/blob/master/README.rst" rel="noreferrer" target="_blank">https://github.com/mad-cocktail/gin/blob/master/README.rst</a><br>
>><br>
>> ...I can say parse_transform is not the solution Erlang needs.<br>
>><br>
>> > There’s no point to add new syntax to the language.<br>
>><br>
>> Yes we need it, an easy to use built-in "in (tuple or list I'm not<br>
>> sure of the right semantic)" syntactic sugar for guards.<br>
>><br>
>> Hope some other advices.<br>
>><br>
>> Florent<br>
>><br>
>> > /Frank<br>
>> ><br>
>> >> Hello everybody,<br>
>> >><br>
>> >> I'm not very experimented in Erlang but I read carefully books and<br>
>> >> official documention.<br>
>> >><br>
>> >> It seems to me that the guards syntax is not as good as it should be,<br>
>> >> i.e. too much verbose for multiple values.<br>
>> >><br>
>> >> do(val1) -> val1;<br>
>> >> do(val2) -> val2;<br>
>> >> do(val3) -> val3;<br>
>> >> do(val4) -> val4;<br>
>> >> do(val5) -> val5.<br>
>> >><br>
>> >> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4;<br>
>> >> Val =:= val5 -> Val.<br>
>> >><br>
>> >> It's boring and error prone to write.<br>
>> >><br>
>> >> Has a "in tuple" syntax already be considered ? Something like :<br>
>> >><br>
>> >> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val.<br>
>> >><br>
>> >> Cheers<br>
>> >><br>
>> >> Florent<br>
>> >><br>
>> >> --<br>
>> >> FLOSS Engineer & Lawyer<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>
>><br>
>><br>
>><br>
>> --<br>
>> FLOSS Engineer & Lawyer<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>
<br>
<br>
<br>
-- <br>
FLOSS Engineer & Lawyer<br>
</blockquote></div>