<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Everybody seems to be chasing after how to express "X in [...]" as a guard</div><div class="gmail_default" style="font-family:monospace,monospace">without responding to the suggestion of copying SML/NJ's "or patterns" as</div><div class="gmail_default" style="font-family:monospace,monospace">Erlang has already copied andalso and orelse from SML.  "or patterns" do</div><div class="gmail_default" style="font-family:monospace,monospace">not introduce a newreserved word, do not make a special case of a function</div><div class="gmail_default" style="font-family:monospace,monospace">in a module other than erlang". and are strictly more general than "_ in _".</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I am also puzzled that nobody seems to be concerned that the one and only</div><div class="gmail_default" style="font-family:monospace,monospace">example we have of a use case is code that should never be written in the</div><div class="gmail_default" style="font-family:monospace,monospace">first place because it requires frequent maintenance effort (where it needs</div><div class="gmail_default" style="font-family:monospace,monospace">to be changed or not does not matter, it still needs to be CHECKED with each</div><div class="gmail_default" style="font-family:monospace,monospace">new release of Unicode, and Unicode changes quite often).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">As an exercise, I wrote a little script to parse UnicodeData.txt and</div><div class="gmail_default" style="font-family:monospace,monospace">write lines like -- I am on another machine so this is not an actual</div><div class="gmail_default" style="font-family:monospace,monospace">example --</div><div class="gmail_default" style="font-family:monospace,monospace">   fraction(9999) -> 3/11; % VULGAR FRACTION THREE ELEVENTHS</div><div class="gmail_default" style="font-family:monospace,monospace">...</div><div class="gmail_default" style="font-family:monospace,monospace">   fraction(C) when is_integer(C), C >= 0 -> undef.</div><div class="gmail_default" style="font-family:monospace,monospace">Plug it into your build tool of choice, and the code automatically</div><div class="gmail_default" style="font-family:monospace,monospace">gets correctly updated whenever a new version of Unicode is installed.</div><div class="gmail_default" style="font-family:monospace,monospace">With a little more work, you could configure it to support multiple</div><div class="gmail_default" style="font-family:monospace,monospace">versions of Unicode.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">This is code that should NOT be written by hand.</div><div class="gmail_default" style="font-family:monospace,monospace">If anything, we need to retain the current setup so that the pain</div><div class="gmail_default" style="font-family:monospace,monospace">of trying to do the wrong thing triggers the realisation that the</div><div class="gmail_default" style="font-family:monospace,monospace">the fault is not in Erlang.</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 19:42, Richard O'Keefe <<a href="mailto:raoknz@gmail.com">raoknz@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"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">I must repeat, we do not need any new syntax.</div><div class="gmail_default" style="font-family:monospace,monospace">We just need the special case of lists:member/2</div><div class="gmail_default" style="font-family:monospace,monospace">with a fixed-length list argument to be accepted</div><div class="gmail_default" style="font-family:monospace,monospace">in a guard.  This is a relatively minor change</div><div class="gmail_default" style="font-family:monospace,monospace">to the compiler.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">If any syntactic extension were involved,</div><div class="gmail_default" style="font-family:monospace,monospace">SML/NJ allows (P1 | ... | Pn) anywhere that</div><div class="gmail_default" style="font-family:monospace,monospace">a pattern is allowed.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">However, this particular example strikes me as</div><div class="gmail_default" style="font-family:monospace,monospace">a perfect example of something that should NOT</div><div class="gmail_default" style="font-family:monospace,monospace">repeat NOT be done by pattern matching.  Why?</div><div class="gmail_default" style="font-family:monospace,monospace">Because "does this codepoint represent a vulgar</div><div class="gmail_default" style="font-family:monospace,monospace">fraction in Unicode" is not a question with a</div><div class="gmail_default" style="font-family:monospace,monospace">fixed answer.  Unicode keeps on growing.  The</div><div class="gmail_default" style="font-family:monospace,monospace">*right* question is "does codepoint X represent</div><div class="gmail_default" style="font-family:monospace,monospace">a vulgar fraction in Unicode version Y", and</div><div class="gmail_default" style="font-family:monospace,monospace">you not only do not want to express that kind</div><div class="gmail_default" style="font-family:monospace,monospace">of thing in code, you don't want to, because</div><div class="gmail_default" style="font-family:monospace,monospace">Unicode keeps on growing, new versions keep on</div><div class="gmail_default" style="font-family:monospace,monospace">coming out.  You want to be able to load a new</div><div class="gmail_default" style="font-family:monospace,monospace">Unicode Data release *without* rewriting your</div><div class="gmail_default" style="font-family:monospace,monospace">Erlang code.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Alternativey, this appears to be an excellent</div><div class="gmail_default" style="font-family:monospace,monospace">example of code that should be *generated*, not</div><div class="gmail_default" style="font-family:monospace,monospace">*written*, and who cares how hard the compiler</div><div class="gmail_default" style="font-family:monospace,monospace">has to work?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Mar 2019 at 08:43, Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@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"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2019 at 8:36 PM Fred Hebert <<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</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"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div>OTP-21 includes the new BIFs erlang:map_get(Key, Map) and erlang:map_size(Map) for these reasons. Only lists:member is missing. <br></div></div></div>
</blockquote></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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?<br></div><div><br></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_7851562650188958261gmail-m_4897575150146470399gmail_signature">J.</div></div>
_______________________________________________<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>
</blockquote></div>
</blockquote></div>