[erlang-questions] Guards syntax for multiple values

[Brujo Benavides]

Sorry Florent, but I don’t understand what you can’t combine with other tests and only can return true means in this context.
In any case, if your situation involves more context than just is_fraction/1, it would be nice if you could provide it so others can really understand the problem you’re facing (i.e. as Richard put it: We really need an actual concrete example of real code to discuss).
Cheers!

Brujo Benavides <http://about.me/elbrujohalcon>



> On 25 Mar 2019, at 11:00, Florent Gallaire <fgallaire@REDACTED> wrote:
> 
>> Well on the first example, there are no guards. I pretty much doubt that there is an illegal guard expression there :P
> 
> Yes excuse me for my wrong sentence. I was talking about
> lists:member/2 in a guard:
> is_fraction(X) when lists:member(X, "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒") -> true.
> which is not possible.
> 
> is_fraction(X) -> lists:member(X, "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒").
> is not good for me because you can't combine with other tests and only
> can return true.
> 
> So I really think Erlang need the "in list" syntax for guards.
> 
> Florent
> 
>> But the code was poorly written, I grant you that. I fixed it (and i actually checked that it compiled this time):
>> 
>> is_fraction(X) -> lists:member(X, "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒").
>> 
>> is_fraction_with_guards(X) when $¼ =< X, X =< $¾ -> true;
>> is_fraction_with_guards(X) when $⅐ =< X, X =< $⅞ -> true;
>> is_fraction_with_guards(_) -> false.
>> 
>> ________________________________
>> Brujo Benavides
>> 
>> 
>> 
>> On 25 Mar 2019, at 10:12, Florent Gallaire <fgallaire@REDACTED> wrote:
>> 
>> Hello Brujo,
>> 
>> Thanks for your answer.
>> 
>> Why not just…
>> 
>> is_fraction(X) -> lists:member(X, "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒”).
>> 
>> 
>> Because it's not possible: "illegal guard expression".
>> 
>> Or, if you really really want to use function clause heads, pattern-matching and guards:
>> 
>> is_fraction(X) when $¼ =< X =< $¾ -> true;
>> is_fraction(X) when $⅐ =< X <= $⅞ -> true;
>> is_fraction(_) -> false.
>> 
>> For these kinds of character manipulation things, using the fact that they’re just integers under-the-hood is not a bad idea.
>> 
>> 
>> Yes you're right in this case, but it remains a trick so most of the
>> time it's not applicable.
>> 
>> Cheers
>> 
>> Cheers!
>> 
>> ________________________________
>> Brujo Benavides
>> 
>> 
>> 
>> On 25 Mar 2019, at 09:38, Florent Gallaire <fgallaire@REDACTED> wrote:
>> 
>> Hello Richard,
>> 
>> Thanks for your answer.
>> 
>> lists:member(X, [X1,X2,X3,X4]) answers true or false.
>> There is no fundamental reason that the compiler could not
>> expand that in-line to (X =:= X1 orselse ... orelse X =:= X4)
>> when the shape of the list is known.  So we *definitely* need
>> no new syntax.
>> 
>> 
>> So if there's no reason the compiler could not do it, we *really*
>> should have a new syntax.
>> 
>> We really need an actual concrete example of real code to discuss.
>> 
>> 
>> The developed version of the is_fraction/1 function:
>> 
>> is_fraction($½) -> true;
>> is_fraction($⅓) -> true;
>> is_fraction($⅔) -> true;
>> is_fraction($¼) -> true;
>> is_fraction($¾) -> true;
>> is_fraction($⅕) -> true;
>> is_fraction($⅖) -> true;
>> is_fraction($⅗) -> true;
>> is_fraction($⅘) -> true;
>> is_fraction($⅙) -> true;
>> is_fraction($⅚) -> true;
>> is_fraction($⅐) -> true;
>> is_fraction($⅛) -> true;
>> is_fraction($⅜) -> true;
>> is_fraction($⅝) -> true;
>> is_fraction($⅞) -> true;
>> is_fraction($⅑) -> true;
>> is_fraction($⅒) -> true;
>> is_fraction(_) -> false.
>> 
>> The awful actual "with a guard" version:
>> 
>> is_fraction(X) when X =:= $½; X =:= $⅓; X =:= $⅔; X =:= $¼; X =:= $¾;
>> X =:= $⅕; X =:= $⅖; X =:= $⅗; X =:= $⅘; X =:= $⅙; X =:= $⅚; X =:= $⅐;
>> X =:= $⅛; X =:= $⅜; X =:= $⅝; X =:= $⅞; X =:= $⅑; X =:= $⅒ -> true;
>> is_fraction(_) -> false.
>> 
>> The pretty, easy and obviously needed "with in list syntactic sugar" version :
>> 
>> is_fraction(X) when X in "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒" -> true;
>> is_fraction(_) -> false.
>> 
>> It clearly speaks for itself.
>> 
>> Cheers.
>> 
>> On Mon, 25 Mar 2019 at 18:12, Florent Gallaire <fgallaire@REDACTED> wrote:
>> 
>> 
>> Frank thanks for your answer.
>> 
>> You’re probably new to Erlang.
>> 
>> 
>> Yes, but...
>> 
>> You can achieve the same with parse_transform:
>> https://github.com/mad-cocktail/gin/blob/master/README.rst
>> 
>> 
>> ...I can say parse_transform is not the solution Erlang needs.
>> 
>> There’s no point to add new syntax to the language.
>> 
>> 
>> Yes we need it, an easy to use built-in "in (tuple or list I'm not
>> sure of the right semantic)" syntactic sugar for guards.
>> 
>> Hope some other advices.
>> 
>> Florent
>> 
>> /Frank
>> 
>> Hello everybody,
>> 
>> I'm not very experimented in Erlang but I read carefully books and
>> official documention.
>> 
>> It seems to me that the guards syntax is not as good as it should be,
>> i.e. too much verbose for multiple values.
>> 
>> do(val1) -> val1;
>> do(val2) -> val2;
>> do(val3) -> val3;
>> do(val4) -> val4;
>> do(val5) -> val5.
>> 
>> do(Val) when Val =:= val1; Val =:= val2; Val =:= val3; Val =:= val4;
>> Val =:= val5 -> Val.
>> 
>> It's boring and error prone to write.
>> 
>> Has a "in tuple" syntax already be considered ? Something like :
>> 
>> do(Val) when Val in {val1, val2, val3, val4, val5} -> Val.
>> 
>> Cheers
>> 
>> Florent
>> 
>> --
>> FLOSS Engineer & Lawyer
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
>> 
>> 
>> 
>> --
>> FLOSS Engineer & Lawyer
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
>> 
>> 
>> 
>> --
>> FLOSS Engineer & Lawyer
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
>> 
>> 
>> 
>> --
>> FLOSS Engineer & Lawyer
>> 
>> 
> 
> 
> -- 
> FLOSS Engineer & Lawyer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190325/deccbc26/attachment.htm>