|
|
123
|
|
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
You’re probably new to Erlang.
You can achieve the same with parse_transform:
There’s no point to add new syntax to the language. /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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Take this as a code smell. There is probably an abstraction missing in your data struc
On Sat, 23 Mar 2019 at 20:40, Florent Gallaire < [hidden email]> wrote: 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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.
However, I must repeat that if this happens often enough in your code to be "boring" you need to give serious thought to changing your data structure. Things that share a processing path should be given a common structure.
We really need an actual concrete example of real code to discuss.
On Mon, 25 Mar 2019 at 18:12, Florent Gallaire < [hidden email]> 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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Pretty easy to do with Elixir - also runs on beam and is a bit more expressive e.g. iex(1)> "foo" in ["foo","bar"] true iex(4)> defmodule T do ...(4)> def f(x) when x in ["foo","bar"] do ...(4)> true ...(4)> end ...(4)> def f(x), do: false ...(4)> end warning: variable "x" is unused (if the variable is not meant to be used, prefix it with an underscore) iex:8
{:module, T, <<70, 79, 82, 49, 0, 0, 4, 100, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 128, 0, 0, 0, 15, 8, 69, 108, 105, 120, 105, 114, 46, 84, 8, 95, 95, 105, 110, 102, 111, 95, 95, 7, 99, 111, 109, 112, ...>>, {:f, 1}} iex(5)> T.f f/1 iex(5)> T.f("bar") true iex(6)> T.f("baz") false
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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 < [hidden email]> 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
>> >> [hidden email]
>> >> http://erlang.org/mailman/listinfo/erlang-questions>>
>>
>>
>> --
>> FLOSS Engineer & Lawyer
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Hey Florent,
Why not just…
is_fraction(X) -> lists:member(X, "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒”).
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.
Cheers!
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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
-- FLOSS Engineer & Lawyer _______________________________________________ erlang-questions mailing list [hidden email]http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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 < [hidden email]> 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 < [hidden email]> 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
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
> --
> FLOSS Engineer & Lawyer
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
> --
> FLOSS Engineer & Lawyer
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions>
>
--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Well on the first example, there are no guards. I pretty much doubt that there is an illegal guard expression there :P
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.
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 thetime it's not applicable.CheersCheers!
________________________________
Brujo Benavides
On 25 Mar 2019, at 09:38, Florent Gallaire <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
-- FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
> 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 < [hidden email]> 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 < [hidden email]> 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 < [hidden email]> 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
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
> --
> FLOSS Engineer & Lawyer
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
> --
> FLOSS Engineer & Lawyer
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
> --
> FLOSS Engineer & Lawyer
>
>
--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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!
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 aboutlists: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 onlycan return true.So I really think Erlang need the "in list" syntax for guards.FlorentBut 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
--
FLOSS Engineer & Lawyer
-- FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
I would second this. It would be great to be able to say "when Val in
[a, b, c]" and that be translated to "when Val =:= a; Val =:= b; Val =:=
c" automatically. It's just nicer to read and write.
And since strings are lists this would also work: 'when Val in
"=!~._-"'. I have a lot of HTTP parsing code that would benefit from
such a construct.
I suppose "when Val in [a, b, c], Flag =:= true" would have to be
translated as "Val =:= a, Flag =:= true; Val =:= b, Flag =:= true; Val
=:= c, Flag =:= true" as well, due to how ;/, work in guards.
Cheers,
On 23/03/2019 04:24, Florent Gallaire wrote:
> 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
>
--
Loïc Hoguin
https://ninenines.eu_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
An alternative notation is that of or-patterns. Here from OCaml:
type foo = A | B | C | D
let is_frac x = match x with
A | B | C -> true
| _ -> false
Abusing erlang notation, you would write something like
is_frac(a); is_frac(b); is_frac(c) -> true; is_frac(_) -> false.
for this variant. As for a hint why you would prefer an or-pattern over list membership in a typed language, consider the compilation of
let is_frac x = match x with
A | B | C | D -> true
| _ -> false
This returns a warning: "Warning 11: this match case is unused." because the latter wildcard match on _ can never be reached.
I would second this. It would be great to be able to say "when Val in
[a, b, c]" and that be translated to "when Val =:= a; Val =:= b; Val =:=
c" automatically. It's just nicer to read and write.
And since strings are lists this would also work: 'when Val in
"=!~._-"'. I have a lot of HTTP parsing code that would benefit from
such a construct.
I suppose "when Val in [a, b, c], Flag =:= true" would have to be
translated as "Val =:= a, Flag =:= true; Val =:= b, Flag =:= true; Val
=:= c, Flag =:= true" as well, due to how ;/, work in guards.
Cheers,
On 23/03/2019 04:24, Florent Gallaire wrote:
> 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
>
--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
-- J.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
On 3/25/19 9:00 AM, Florent Gallaire wrote:
> 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.
http://erlang.org/doc/reference_manual/expressions.html#guard-sequencesexplains
The set of valid guard expressions (sometimes called guard tests) is
a subset of the set of valid Erlang expressions. The reason for
restricting the set of valid expressions is that evaluation of a
guard expression must be guaranteed to be free of side
effects. Valid guard expressions are the following:
and later on, there's a list of "blessed" functions that are allowed in
guard expressions.
My experience with Erlang is entirely as a hobbyist, but what are the
pros, cons, and possibilities of expanding the list of such "blessed"
functions? Many of the functions in the list module have no side
effects, and could make some Erlang code more concise.
That said, I've also discovered (or more likely rediscovered) that
breaking down such functions and guard clauses one more layer also leads
to more concise code. I don't know Florent's use case, but I could
imagine breaking it down one more level into something like this:
process(X) ->
Classification = classify(X),
process(X, Classification).
process(X, fraction) ->
%% process fractions here
ok;
process(X, url_character) ->
%% process URL characters here
ok;
process(X, whitespace) ->
%% process whitespace here
ok;
process(X, UnknownClassification) ->
%% handle an unknown X here
ok.
Or maybe all that does is push the problem into the implementation
of classify/1.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
I personally have always wanted to see it possible to specify certain functions as "pure" so that they can be used in a guard.
I understand why using any random function in a guard is a bad idea. But some ability to override should be possible, even if it emitted a warning of some sort.
Typically, I've seen patterns like so when needing to use a custom function in a guard:
```
function(X) ->
case custom_guard(X) of
true -> function_guarded(X)
end.
```
While a terrible example, the point is there are ways to work around it, and sometimes people have to work around it. So the restriction is bypassed anyway, surely there is a way to dissuade people from using any function in a guard, but allowing people to carefully write a function that would be guard safe. Parse transforms can be way more dangerous, and yet we still allow them, and their use is certainly dissuaded.
Personally, I think just marking a function as "pure" should be enough to allow it in a guard, possibly with a warning. No need to auto-detect what functions are pure or not, though possibly we could double check the "pure" functions to verify they only call out to the current "blessed" functions and others marked as "pure".
On Monday, March 25, 2019, 11:51:04 AM EDT, Dan Sommers < [hidden email]> wrote:
On 3/25/19 9:00 AM, Florent Gallaire wrote: > 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. http://erlang.org/doc/reference_manual/expressions.html#guard-sequencesexplains The set of valid guard expressions (sometimes called guard tests) is a subset of the set of valid Erlang expressions. The reason for restricting the set of valid expressions is that evaluation of a guard expression must be guaranteed to be free of side effects. Valid guard expressions are the following: and later on, there's a list of "blessed" functions that are allowed in guard expressions. My experience with Erlang is entirely as a hobbyist, but what are the pros, cons, and possibilities of expanding the list of such "blessed" functions? Many of the functions in the list module have no side effects, and could make some Erlang code more concise. That said, I've also discovered (or more likely rediscovered) that breaking down such functions and guard clauses one more layer also leads to more concise code. I don't know Florent's use case, but I could imagine breaking it down one more level into something like this: process(X) -> Classification = classify(X), process(X, Classification). process(X, fraction) -> %% process fractions here ok; process(X, url_character) -> %% process URL characters here ok; process(X, whitespace) -> %% process whitespace here ok; process(X, UnknownClassification) -> %% handle an unknown X here ok. Or maybe all that does is push the problem into the implementation of classify/1.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
Hello Bryan,
thanks for your answer.
Indeed it's very intersting to note that the only thing added to
Erlang guards when designing Elixir has been this "in list" (and "not
in") operator.
For people who don't know about Elixir, it's a BEAM based programming
language with a tremondous succes.
All (alive) programming languages are evolving influenced by others,
Erlang evolve too, even for syntactic sugar, and it's GOOD.
For reasons of taste, I prefer Erlang over Elixir, and my "in list"
operator need comes obviously from my important Python experience.
As Loïc said "It's just nicer to read and write", it's just better for
beginnings, and so better for any programmers, and so better for
Erlang.
Cheers
Le lun. 25 mars 2019 à 12:50, Bryan Hunt
< [hidden email]> a écrit :
>
> Pretty easy to do with Elixir - also runs on beam and is a bit more expressive e.g.
>
> iex(1)> "foo" in ["foo","bar"]
> true
> iex(4)> defmodule T do
> ...(4)> def f(x) when x in ["foo","bar"] do
> ...(4)> true
> ...(4)> end
> ...(4)> def f(x), do: false
> ...(4)> end
> warning: variable "x" is unused (if the variable is not meant to be used, prefix it with an underscore)
> iex:8
>
> {:module, T,
> <<70, 79, 82, 49, 0, 0, 4, 100, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 128,
> 0, 0, 0, 15, 8, 69, 108, 105, 120, 105, 114, 46, 84, 8, 95, 95, 105, 110,
> 102, 111, 95, 95, 7, 99, 111, 109, 112, ...>>, {:f, 1}}
> iex(5)> T.f
> f/1
> iex(5)> T.f("bar")
> true
> iex(6)> T.f("baz")
> false
>
>
--
FLOSS Engineer & Lawyer
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
On Mon, Mar 25, 2019 at 6:03 PM Florent Gallaire <[hidden email]> wrote: For reasons of taste, I prefer Erlang over Elixir, and my "in list"
operator need comes obviously from my important Python experience.
Thinking out loud, I think it might be beneficial to look at two additions:
lists:member - because length(..) is in the set of Valid GuardSeqs and is O(n) maps:is_key maps:get
The latter map variants are arguably even stronger since they have good lookup time, even for very large maps. Writing maps:is_key(X, #{ a => true, b => true }) should be fast and since it is a literal, it can be optimized in a number of ways by the compiler. _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
On Mon, Mar 25, 2019 at 2:03 PM Jesper Louis Andersen < [hidden email]> wrote:
Thinking out loud, I think it might be beneficial to look at two additions:
lists:member - because length(..) is in the set of Valid GuardSeqs and is O(n) maps:is_key maps:get
The latter map variants are arguably even stronger since they have good lookup time, even for very large maps. Writing maps:is_key(X, #{ a => true, b => true }) should be fast and since it is a literal, it can be optimized in a number of ways by the compiler.
OTP-21 includes the new BIFs erlang:map_get(Key, Map) and erlang:map_size(Map) for these reasons. Only lists:member is missing.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
OTP-21 includes the new BIFs erlang:map_get(Key, Map) and erlang:map_size(Map) for these reasons. Only lists:member is missing.
Indeed! Though the documentation doesn't have them as "Allowed in guard tests". We can live without is_key, if we just test against true for now. I tried looking it up and the documentation didn't have them as allowed. But perhaps the code actually allows them if I just tried doing it?
-- J. _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
123
|
Locked
