<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">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_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>