[erlang-questions] Guards syntax for multiple values

[Richard O'Keefe]

Everybody seems to be chasing after how to express "X in [...]" as a guard
without responding to the suggestion of copying SML/NJ's "or patterns" as
Erlang has already copied andalso and orelse from SML.  "or patterns" do
not introduce a newreserved word, do not make a special case of a function
in a module other than erlang". and are strictly more general than "_ in _".

I am also puzzled that nobody seems to be concerned that the one and only
example we have of a use case is code that should never be written in the
first place because it requires frequent maintenance effort (where it needs
to be changed or not does not matter, it still needs to be CHECKED with each
new release of Unicode, and Unicode changes quite often).

As an exercise, I wrote a little script to parse UnicodeData.txt and
write lines like -- I am on another machine so this is not an actual
example --
   fraction(9999) -> 3/11; % VULGAR FRACTION THREE ELEVENTHS
...
   fraction(C) when is_integer(C), C >= 0 -> undef.
Plug it into your build tool of choice, and the code automatically
gets correctly updated whenever a new version of Unicode is installed.
With a little more work, you could configure it to support multiple
versions of Unicode.

This is code that should NOT be written by hand.
If anything, we need to retain the current setup so that the pain
of trying to do the wrong thing triggers the realisation that the
the fault is not in Erlang.


On Tue, 26 Mar 2019 at 19:42, Richard O'Keefe <raoknz@REDACTED> wrote:

> I must repeat, we do not need any new syntax.
> We just need the special case of lists:member/2
> with a fixed-length list argument to be accepted
> in a guard.  This is a relatively minor change
> to the compiler.
>
> If any syntactic extension were involved,
> SML/NJ allows (P1 | ... | Pn) anywhere that
> a pattern is allowed.
>
> However, this particular example strikes me as
> a perfect example of something that should NOT
> repeat NOT be done by pattern matching.  Why?
> Because "does this codepoint represent a vulgar
> fraction in Unicode" is not a question with a
> fixed answer.  Unicode keeps on growing.  The
> *right* question is "does codepoint X represent
> a vulgar fraction in Unicode version Y", and
> you not only do not want to express that kind
> of thing in code, you don't want to, because
> Unicode keeps on growing, new versions keep on
> coming out.  You want to be able to load a new
> Unicode Data release *without* rewriting your
> Erlang code.
>
> Alternativey, this appears to be an excellent
> example of code that should be *generated*, not
> *written*, and who cares how hard the compiler
> has to work?
>
> On Tue, 26 Mar 2019 at 08:43, Jesper Louis Andersen <
> jesper.louis.andersen@REDACTED> wrote:
>
>>
>>
>> On Mon, Mar 25, 2019 at 8:36 PM Fred Hebert <mononcqc@REDACTED> wrote:
>>
>>>
>>> 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
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190327/ebe31937/attachment.htm>