<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">I knew it!  I knew it!</div><div class="gmail_default" style="font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:Arial,Helvetica,sans-serif"> "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒”</span>  <br></div><div class="gmail_default" style="font-family:monospace,monospace">That list is NOT an exhaustive list of all the "VULGAR FRACTION n dTHS" characters!</div><div class="gmail_default" style="font-family:monospace,monospace">It was not even complete back in Unicode 6.3. </div><div class="gmail_default" style="font-family:monospace,monospace">Nor is the version with two integer ranges complete.</div><div class="gmail_default" style="font-family:monospace,monospace">If this list is not *intended* to include all such characters,</div><div class="gmail_default" style="font-family:monospace,monospace">there had better be a very clear and explicit comment saying that it is</div><div class="gmail_default" style="font-family:monospace,monospace">so and why it is so.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Let me put it this way: if the number of cases you want to cover this way</div><div class="gmail_default" style="font-family:monospace,monospace">is sufficiently large that writing it is enough of a pain to comment on,</div><div class="gmail_default" style="font-family:monospace,monospace">considering all the other things you have to do, you almost surely have the</div><div class="gmail_default" style="font-family:monospace,monospace">list wrong.  So I was *expecting* the list to miss something, and it was.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">In fact the list is incomplete in two different ways.</div><div class="gmail_default" style="font-family:monospace,monospace">First, it does not contain all the "VULGAR FRACTION *" characters.</div><div class="gmail_default" style="font-family:monospace,monospace">Second, it does not contain *any* of the "ORIYA FRACTION *",</div><div class="gmail_default" style="font-family:monospace,monospace">"TELUGU FRACTION *", "MALAYALAM FRACTION *", "NORTH INDIC FRACTION *",</div><div class="gmail_default" style="font-family:monospace,monospace">"RUMI FRACTION *", or "COPTIC FRACTION *" characters (and there were</div><div class="gmail_default" style="font-family:monospace,monospace">27 of those in Unicode 6.3), and there is no explanation of why not.</div><div class="gmail_default" style="font-family:monospace,monospace">Seriously, by the time the function is adequately documented as to</div><div class="gmail_default" style="font-family:monospace,monospace">which characters are included, which excluded, and why, the actual</div><div class="gmail_default" style="font-family:monospace,monospace">code is relatively small.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Mar 2019 at 02:13, 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 Brujo,<br>
<br>
Thanks for your answer.<br>
<br>
> Why not just…<br>
><br>
> is_fraction(X) -> lists:member(X, "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒”).<br>
<br>
Because it's not possible: "illegal guard expression".<br>
<br>
> Or, if you really really want to use function clause heads, pattern-matching and guards:<br>
><br>
> is_fraction(X) when $¼ =< X =< $¾ -> true;<br>
> is_fraction(X) when $⅐ =< X <= $⅞ -> true;<br>
> is_fraction(_) -> false.<br>
><br>
> For these kinds of character manipulation things, using the fact that they’re just integers under-the-hood is not a bad idea.<br>
<br>
Yes you're right in this case, but it remains a trick so most of the<br>
time it's not applicable.<br>
<br>
Cheers<br>
<br>
> Cheers!<br>
><br>
> ________________________________<br>
> Brujo Benavides<br>
><br>
><br>
><br>
> On 25 Mar 2019, at 09:38, Florent Gallaire <<a href="mailto:fgallaire@gmail.com" target="_blank">fgallaire@gmail.com</a>> wrote:<br>
><br>
> 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>
><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>
><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>
><br>
> Frank thanks for your answer.<br>
><br>
> You’re probably new to Erlang.<br>
><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>
><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>
><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>
> --<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>
> --<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>
-- <br>
FLOSS Engineer & Lawyer<br>
</blockquote></div>