Front page | perl.perl5.porters |
Postings from June 2022
Re: A troubling thought - smartmatch reïmagined
Thread Previous
|
Thread Next
From:
Aaron Priven
Date:
June 28, 2022 05:29
Subject:
Re: A troubling thought - smartmatch reïmagined
Message ID:
22B514BA-F174-4A5E-9661-7B4397F03345@priven.com
> 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
Thread Previous
|
Thread Next