develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About