[prev in list] [next in list] [prev in thread] [next in thread]
List: perl5-porters
Subject: =?utf-8?Q?Re=3A_A_troubling_thought_-_smartmatch_re=C3=AFmagined?=
From: Aaron Priven <aaron () priven ! com>
Date: 2022-06-28 5:28:39
Message-ID: 22B514BA-F174-4A5E-9661-7B4397F03345 () priven ! com
[Download RAW message or body]
> Maybe - maybe - now that we can distinguish strings vs numbers
> a little better,
Can we, though?
Even aside from the difficulty of determining whether a number can be compared to a \
string, there are lots of times when one might read booleans from a text file or \
database or something, where it's not clear whether "0" is a boolean or a number or a \
string, or whether "" is a boolean or a string. It seems to me that if we want to be \
certain, then at best, we really only have three different types: undef, reference, \
and everything else.
Smartmatch was the previous decade's attempt to get around Perl's lack of types, and \
builtin::created_as_string etc. is this decade's. In each case, it works sometimes, \
but not all the time, and it's not always obvious to everyone what a "string-like \
nature" or "numerical nature" is, to quote from the builtin docs. It's less obscure \
than smartmatch was, but only somewhat.
So I think you were right the first time. I like, in general, your "match (VALUE : \
OPERATOR)" syntax. I also think your proposed operators are very helpful. I \
strongly believe "any {$_ eq ‘A' } @arr" is, while more flexible and very valuable, \
less comprehensible to most people than "‘A' elem @arr" (although "‘A' in @arr" \
would be even more clear, and I believe that clarity would worth losing the \
parallelism with ∈).
(I'd suggest <== as a way of spelling ∈ in 7-bit ASCII, if that doesn't break \
anything. I admit I don't know whether it would.)
I don't love the word "match," since most of the time when we use the word "match" in \
discussing Perl, we're talking about regular expression matching. I would just as \
soon go back to "given." While "when" is deeply problematic, now that there's no \
lexical $_, "given" is basically the same as "for scalar", if I understand \
correctly. But it's not that important.
I would suggest a couple of things. First, match (or given) without an operator \
should just default to a Boolean test.
match ($x) { # or given ($x), both meaning "for (scalar $x)"
case ($_ eq ‘A') {
…
}
case ($_ == 0) {
…
}
}
And this could work with "for" as well.
for ($x, $y) {
case ($_ eq ‘A') {
…
}
case ($_ == 0) {
…
}
}
Admittedly, this doesn't add that much, because "case" becomes just equivalent to
if (EXPR) {
…
next;
}
But it's convenient to be able to encapsulate that in a single statement in one place
More interestingly though, it leads to the idea of extending for to include your \
operator:
for (@x, @q : == ) {
# I have not checked to see if this syntax could work
case (0) {
…
}
case (1) {
…
}
}
I don't really know if that would get much use, but maybe it would. And I think \
making "for" and "match" (or "given") so clearly parallel is appealing.
--
Aaron Priven, aaron@priven.com, www.priven.com/aaron
[Attachment #3 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><div class=""><pre style="overflow-x: auto; \
white-space: pre-wrap; word-wrap: break-word; background-color: rgb(255, 255, 255);" \
class=""><font face="Georgia" class="">> Maybe - maybe - now that we can \
distinguish strings vs numbers > a little better, </font></pre></div><div \
class="">Can we, though?</div><div class=""><br class=""></div><div class="">Even \
aside from the difficulty of determining whether a number can be compared to a \
string, there are lots of times when one might read booleans from a text file or \
database or something, where it's not clear whether "0" is a boolean or a number or a \
string, or whether "" is a boolean or a string. It seems to me that if we want \
to be certain, then at best, we really only have three different types: undef, \
reference, and everything else. </div><div class=""><br class=""></div><div \
class="">Smartmatch was the previous decade's attempt to get around Perl's lack of \
types, and builtin::created_as_string etc. is this decade's. In each case, it works \
sometimes, but not all the time, and it's not always obvious to everyone what a \
"string-like nature" or "numerical nature" is, to quote from the builtin docs. It's \
less obscure than smartmatch was, but only somewhat.</div><div class=""><br \
class=""></div><div class="">So I think you were right the first time. I like, \
in general, your "match (VALUE : OPERATOR)" syntax. I also think your proposed \
operators are very helpful. I strongly believe "any {$_ eq ‘A' } @arr" is, \
while more flexible and very valuable, less comprehensible to most people than "‘A' \
elem @arr" (although "‘A' in @arr" would be even more clear, and I believe that \
clarity would worth losing the parallelism with ∈). </div><div \
class=""><br class=""></div><div class="">(I'd suggest <== as a way of \
spelling ∈ in 7-bit ASCII, if that doesn't break anything. I admit I don't \
know whether it would.)</div><div class=""><br class=""></div><div class="">I don't \
love the word "match," since most of the time when we use the word "match" in \
discussing Perl, we're talking about regular expression matching. I would just \
as soon go back to "given." While "when" is deeply problematic, now that \
there's no lexical $_, "given" is basically the same as "for scalar", if I \
understand correctly. But it's not that important.</div><div class=""><br \
class=""></div><div class="">I would suggest a couple of things. First, match (or \
given) without an operator should just default to a Boolean test.</div><div \
class=""><br class=""></div><div class=""><font face="SourceCodePro-Regular" \
class="">match ($x) { # or given ($x), both meaning "for (scalar \
$x)"</font></div><div class=""><font face="SourceCodePro-Regular" class=""> \
case ($_ eq ‘A') {</font></div><div class=""><font \
face="SourceCodePro-Regular" class=""> …</font></div><div \
class=""><font face="SourceCodePro-Regular" class=""> }</font></div><div \
class=""><div class=""><font face="SourceCodePro-Regular" class="">case ($_ == 0) \
{</font></div><div class=""><font face="SourceCodePro-Regular" class=""> \
…</font></div><div class=""><font face="SourceCodePro-Regular" \
class=""> }</font></div></div><div class=""><font \
face="SourceCodePro-Regular" class="">}</font></div><div class=""><br \
class=""></div><div class="">And this could work with "for" as well.</div><div \
class=""><br class=""></div><div class=""><div class=""><font \
face="SourceCodePro-Regular" class="">for ($x, $y) { </font></div><div \
class=""><font face="SourceCodePro-Regular" class=""> case ($_ eq ‘A') \
{</font></div><div class=""><font face="SourceCodePro-Regular" class=""> \
…</font></div><div class=""><font face="SourceCodePro-Regular" \
class=""> }</font></div><div class=""><div class=""><font \
face="SourceCodePro-Regular" class=""> case ($_ == 0) {</font></div><div \
class=""><font face="SourceCodePro-Regular" class=""> \
…</font></div><div class=""><font face="SourceCodePro-Regular" \
class=""> }</font></div></div><div class=""><font \
face="SourceCodePro-Regular" class="">}</font></div></div><div class=""><br \
class=""></div><div class="">Admittedly, this doesn't add that much, because "case" \
becomes just equivalent to </div><div class=""><br class=""></div><div \
class=""><font face="SourceCodePro-Regular" class="">if (EXPR) {</font></div><div \
class=""><font face="SourceCodePro-Regular" class=""> \
…</font></div><div class=""><font face="SourceCodePro-Regular" \
class=""> next;</font></div><div class=""><font \
face="SourceCodePro-Regular" class="">}</font></div><div class=""><br \
class=""></div><div class="">But it's convenient to be able to encapsulate that in a \
single statement in one place</div><div class=""><br class=""></div><div \
class="">More interestingly though, it leads to the idea of extending for to include \
your operator:</div><div class=""><br class=""></div><div class=""><font \
face="SourceCodePro-Regular" class="">for (@x, @q : == ) { </font></div><div \
class=""><font face="SourceCodePro-Regular" class=""># I have not checked to see if \
this syntax could work</font></div><div class=""><font face="SourceCodePro-Regular" \
class=""> case (0) {</font></div><div class=""><font \
face="SourceCodePro-Regular" class=""> …</font></div><div \
class=""><font face="SourceCodePro-Regular" class=""> }</font></div><div \
class=""><font face="SourceCodePro-Regular" class=""> case (1) \
{</font></div><div class=""><font face="SourceCodePro-Regular" class=""> \
…</font></div><div class=""><font face="SourceCodePro-Regular" \
class=""> }</font></div><div class=""><font face="SourceCodePro-Regular" \
class="">}</font></div><div class=""><br class=""></div><div class="">I don't really \
know if that would get much use, but maybe it would. And I think making "for" \
and "match" (or "given") so clearly parallel is appealing.</div><div class=""><br \
class=""></div><div class="">
-- <br class="">Aaron Priven, <a href="mailto:aaron@priven.com" \
class="">aaron@priven.com</a>, <a href="http://www.priven.com/aaron" \
class="">www.priven.com/aaron</a>
</div>
<br class=""></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic