develooper Front page | perl.perl5.porters | Postings from August 2012

Re: fixing smartmatch just hard enough (and when, too)

Thread Previous | Thread Next
Peter Scott
August 29, 2012 22:40
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
On Sun, 26 Aug 2012 12:52:14 -0700, Father Chrysostomos wrote:
> Do we really need smart match at all?

Please, please, what he said.  All of the below is FWIW, and in case a 
new voice is of any help.  I have been unable to find a way to be 
comfortable putting ~~ in any of my teaching materials or use it in my 
own programs.  It looks on the face of it as though it is making hard 
things simpler, but instead it is making some relatively easy and only 
slightly less succinct operations more succinct but also more obscure.  

If it's not to be considered something to make a beginner's life easier, 
then what about the more advanced developer?  Yet I've never encountered 
a situation where I've felt the absence of smartmatch, or even now can 
see that it would make a difference I would appreciate to any past 
situation.  Does anyone have a killer app for this?

Every hypothetical case I've seen involving wildly heterogeneous 'when' 
clauses in the same given block has been contrived example-ware.  I don't 
see those in real life often enough to justify the burden that having ~~ 
in the language would exact in too many other cases.

If I want any of the junctive operations, I find it clearer to use the 
apposite function from Perl6::Junctions, List::MoreUtils, or 
List::Compare.  Then I can see what I'm getting and don't have to 
mentally visualize the type dispatch table for ~~.

If I wanted to construct a subroutine that smartmatched arguments that 
could really be of any type, I'd be so paranoid every time I looked at 
the code that I'd be forever reconsidering what all possible argument 
types could do.  Is the type dispatch table for ~~ obvious enough that 
people can internalize it rapidly without having to refer to it 
constantly?  So far, I haven't.

> implement two syntactic special cases:
>   # literal numbers
>   when(0)
>   when(1)
>   when(0xff)
>   when(0b101110)
>   when(023476)
>   # literal strings
>   when('foo')
>   when("foo")
>   when(q "foo")
>   when(qq "foo")
> and *nothing* else.  Everything else would be a boolean, including
> when($foo).  Anything else is madness; it really is.

I'm afraid even that looks like madness, as useful as it appears.  
Because if I have 'when( 3.14159 ) ... when ( 2.71828 )' then why should 
it behave differently when I refactor to turn magic numbers into symbols: 
'when ( $PI ) ... when ( $E )'?  How can I explain that?  Or am I missing 
something that would enable that to work?  Even then, if someone's read 
from input "003" into $num and then does a ~~ on $x = 3, how to explain 
that it's not coercing to a number?  It's too much to think about, when 
using an operator that looks deceptively simple.

It's fundamental to Perl that you have to know whether to use == or eq.  
Trying to get ~~ to DWIM the right choice seems to mean that too much 
information has been lost.

Even in the case of when (1) ... when (2) ... when (3), if there's more 
than 2 or 3 cases in that block I usually refactor to a hash or dispatch 
table anyway.

If there were a natural intuitive interpretation of ~~ I think it would 
have emerged from all this brainstorming by now.

> Then we can just deprecate ~~.

I regret to say that I have come to think of it as the too-smart-for-its-
own-good-match operator.  I am having pseudohash flashbacks.

Hope this helps.

Peter Scott

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About