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