develooper Front page | perl.perl5.porters | Postings from October 2015

Re: YA smartmatch proposal [ was: Re: smartmatch needs your eyes]

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
October 12, 2015 10:41
Subject:
Re: YA smartmatch proposal [ was: Re: smartmatch needs your eyes]
Message ID:
20151012104108.GN16789@iabyn.com
On Thu, Oct 08, 2015 at 02:57:27AM +0200, Aristotle Pagaltzis wrote:
> * Dave Mitchell <davem@iabyn.com> [2015-10-07 10:30]:
> > I think 95% of what people actually *want* a smartmatch system for
> > is so that they can write code of one of these three forms:
> 
> Mostly agree.
> 
> > Why get rid of the smartmatch operator? I've never really seen the
> > point of it, apart from being something that exposes the underlying
> > mechanism of when(), c.f. readline() for <>. If we do keep it, then it
> > should have exactly the same semantics as I've described above for
> > when().
> 
> Disagree. Plenty of times I’ve written interfaces that let the user say
> watch to match, so I’ve written various ad-hoc incarnations of “if you
> pass a string, it will be compared exactly, if you pass a regexp object
> it will be matched, if you pass a sub it will be called and the return
> value will be checked for truthiness”. It would be real nice if all of
> that could be replaced with just “pass a smarmatch operand” and all the
> code implementing this sort of thing could go away.


Having thought about this some more, I think the most important point I
want to make is that any smartmatch operator should be completely separate
from when() or its successors, and that when() et al should be a
compile-time determination, not based on the runtime value of its arg.

If people agree with that in principle, then rest is mere detail :-).

So if people think a smartmatch operator is useful and can reach consensus
on its semantics, I'm perfectly happy for that. I have no particularly
strong opinions on its semantics, since I've never found a need for
personally.

As for how to achieve "when" functionality. I think we need something that
makes use of an implicit $_, otherwise as you say it's no different
than an 'if' with an implicit break, so hardly worth bothering with.

I'm not terribly keen on the idea of having multiple keywords, since I
think when() with different classes of literal is clear and
straightforward enough, with the possible exception of constant functions.


-- 
Hofstadter's Law: It always takes longer than you expect, even when you
take into account Hofstadter's Law.

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