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:
Paul "LeoNerd" Evans
Date:
October 7, 2015 17:35
Subject:
Re: YA smartmatch proposal [ was: Re: smartmatch needs your eyes]
Message ID:
20151007183517.799a13e3@shy.leonerd.org.uk
On Wed, 7 Oct 2015 09:24:45 +0100
Dave Mitchell <davem@iabyn.com> wrote:

> 3. when { FOO } has condition FOO.
> 
> For example:
> 
>     use constant ANS => 42;
>     use constant ME  => "davem";
> 
>     when (undef)   # equivalent to when { !defined($_) }
>     when (42)      # equivalent to when { $_ == 42 }
>     when (ANS)     # equivalent to when { $_ == 42 }
>     when (42.1)    # equivalent to when { $_ == 42.1 }
>     when ("42")    # equivalent to when { $_ eq "42" }
>     when ("davem") # equivalent to when { $_ eq "davem" }
>     when (ME)      # equivalent to when { $_ eq "davem" }
>     when ($x)      # equivalent to when { $_ eq $x }

Some trickier cornercases

  3a) dualvar constants:

    use Scalar::Util qw( dualvar );
    use constant THREE => dualvar(3, "3");

    when(THREE)  # eq or == ?

  3b) 'bigint' and friends:

    use bigint;

    when(5)      # 5 is now a Math::BigInt instance surely?

> Rationale:
> 
> 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:

<snip>

Agree.

> Since perl is about making easy things easy, I think that achieving
> the above forms should be our basic goal. If we don't do that, we've
> failed. Of course perl likes to make hard things possible too, but I
> think that is an auxiliary consideration for now.

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(). Then the condition for when(FOO) would be defined as always
> exactly equivalent to  when { $_ ~~ expr }.

Agree doubly-so. I think a lot of people want a simple
dispatch-on-constantish things switch-alike, and the idea of the very
generic smartmatch came along accidentally from Perl 6. We don't
strictly need it to get a switch-alike out of this given/when syntax,
so it makes a lot of sense to consider it a separate operator, and work
on given/when as their own standalone thing.

> Finally, if the smartmatch operator were freed up, then maybe we could
> repurpose it as some sort of recursive grep operator that searches
> though nested arrays and hashes for something. That's just a vague
> thought though.

If we wanted a fancier recursive grep, surely that's more a candidate
for some kind of function in a module of somesort (List::Util?) rather
than really basic syntax using up an infix operator. Much easier to
backport, too.

> Finally finally, regardless of what semantics we finally choose,
> perhaps we should use a new feature name for all this, e.g.
> 
>     use feature 'switch2';
> 
> with 'switch' becoming an error, so that existing code will noisily
> fail to compile rather than failing mysteriously on subtle changes to
> semantics.

A new name could be good, yes. I'm not sure I like the specific
"switch2" but now we're really bikeshedding...

Maybe new keywords while we're at it?

  use feature 'dispatch';

  dispatch($str) {
    on("hello") { say "Hello, there"; }
    on("bye")   { say "Goodbye then"; }
  }

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS

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