Mailing List Archive: Perl: porters

fixing smartmatch (again (still))

Index | Next | Previous | View Threaded

perl.p5p at rjbs

Aug 28, 2012, 11:43 AM

Post #1 of 14 (97 views)
Permalink

fixing smartmatch (again (still))

Let's try again.

First, though, I want to say that I was really happy with the discussion about
this. It was on topic, interesting, and helpful. Even if there *was* a holy
ton of it!

## The New ~~ Operator

$a $b Meaning
======= ======= ======================
Any undef ! defined $a
Any ~~-overloaded ~~ overloading is used
Any Regexp, qr-ol $a =~ $b
Any CodeRef, &{}-ol $b->($a)
Any Any fatal

So, this is the table I proposed in July 2011, and it's what I think we're back
to. No special cases.

There is no question of how ($x=5) somehow became ambiguous, because if $x
contains 5 or "5" is is not allowed as the smartmatcher operator, period. Use
Smart::Match and say stringwise(5) or numwise(5), or pass sub{$_==5}

If both 'qr' and '&{}' are overloaded, '~~' must be overloaded to disambiguate.

Switches are still okay.

## The new behavior of given/when

given ($x) {
when ($y) { ... } # $x ~~ $y
when (4) { ... } # $x == 4
when ('4') { ... } # $x eq 4
}

Deferred/computed values of any sort mean smart match.

Two dead-simple special cases: Numeric literals mean ==. String literals mean
eq.

If you want one case for $x eq a or b or c, then:

given ($x) {
when (stringwise any qw(a b c)) { ... }
}

## What about what Father C. said?

Sprout proposed that smartmarch be jettisoned and that `when` always evaluate
its parameter as a boolean expression, save for the same simple cases above.

For the "$x eq a or b or c" example, that gives us at least two simple choices:

given ($x) {
# Here, "any" returns a "junction" that distributes the eq
when ($_ eq any qw(a b c)) { ... }
}

Or:

given ($x) {
# Here, stringwise implies the "$_ eq"
when (stringwise any qw(a b c)) { ... }
}

My thoughts on this are:

• I like the idea that we can have matcher objects that can be passed in
more succinctly than a sub. ->set_matcher(qr/../) or ->set_matcher($obj)
both seems simpler to me than ->set_matcher(sub { /.../ }) or
->set_matcher(sub { $obj->match($_) })

• If we do, then Smart::Match and many other things keep working as they have
without needing to be rewritten. This is nice.

As Father Chrysostomos suggests, perl does not *need* smartmatch. Really, it
doesn't need need features. My question is, does perl benefit more from this
fix to smartmatching than it does from simply removing it? I believe it does.

--
rjbs

Attachments:

signature.asc (0.48 KB)

rs at 474

Aug 28, 2012, 12:17 PM

Post #2 of 14 (98 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

On Tue, 2012-08-28 at 14:43 -0400, Ricardo Signes wrote:
> As Father Chrysostomos suggests, perl does not *need* smartmatch. Really, it
> doesn't need need features. My question is, does perl benefit more from this
> fix to smartmatching than it does from simply removing it? I believe it does.

I agree that it is a benefit. I also think that this minimalistic
approach allows many things to be handled and experimented with on CPAN,
which I'm always glad about.

So, personally, I'd be very happy to have and use the described feature.

regards
--
Robert 'phaylon' Sedlacek

Perl 5 Consultant for
Shadowcat Systems Limited - http://shadowcat.co.uk/

doy at tozt

Aug 28, 2012, 12:42 PM

Post #3 of 14 (94 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

On Tue, Aug 28, 2012 at 02:43:48PM -0400, Ricardo Signes wrote:
>
> Let's try again.
>
> First, though, I want to say that I was really happy with the discussion about
> this. It was on topic, interesting, and helpful. Even if there *was* a holy
> ton of it!
>
> ## The New ~~ Operator
>
> $a $b Meaning
> ======= ======= ======================
> Any undef ! defined $a
> Any ~~-overloaded ~~ overloading is used
> Any Regexp, qr-ol $a =~ $b
> Any CodeRef, &{}-ol $b->($a)
> Any Any fatal
>
> So, this is the table I proposed in July 2011, and it's what I think we're back
> to. No special cases.
>
> There is no question of how ($x=5) somehow became ambiguous, because if $x
> contains 5 or "5" is is not allowed as the smartmatcher operator, period. Use
> Smart::Match and say stringwise(5) or numwise(5), or pass sub{$_==5}
>
> If both 'qr' and '&{}' are overloaded, '~~' must be overloaded to disambiguate.
>
> Switches are still okay.
>
> ## The new behavior of given/when
>
> given ($x) {
> when ($y) { ... } # $x ~~ $y
> when (4) { ... } # $x == 4
> when ('4') { ... } # $x eq 4
> }
>
> Deferred/computed values of any sort mean smart match.
>
> Two dead-simple special cases: Numeric literals mean ==. String literals mean
> eq.
>
> If you want one case for $x eq a or b or c, then:
>
> given ($x) {
> when (stringwise any qw(a b c)) { ... }
> }
>
> ## What about what Father C. said?
>
> Sprout proposed that smartmarch be jettisoned and that `when` always evaluate
> its parameter as a boolean expression, save for the same simple cases above.
>
> For the "$x eq a or b or c" example, that gives us at least two simple choices:
>
> given ($x) {
> # Here, "any" returns a "junction" that distributes the eq
> when ($_ eq any qw(a b c)) { ... }
> }
>
> Or:
>
> given ($x) {
> # Here, stringwise implies the "$_ eq"
> when (stringwise any qw(a b c)) { ... }
> }
>
> My thoughts on this are:
>
> • I like the idea that we can have matcher objects that can be passed in
> more succinctly than a sub. ->set_matcher(qr/../) or ->set_matcher($obj)
> both seems simpler to me than ->set_matcher(sub { /.../ }) or
> ->set_matcher(sub { $obj->match($_) })
>
> • If we do, then Smart::Match and many other things keep working as they have
> without needing to be rewritten. This is nice.
>
> As Father Chrysostomos suggests, perl does not *need* smartmatch. Really, it
> doesn't need need features. My question is, does perl benefit more from this
> fix to smartmatching than it does from simply removing it? I believe it does.

As far as I can tell, this resolves all of the (few) misgivings I had
about the previous version of the proposal. I would be very happy to see
this happen.

-doy

dagolden at cpan

Aug 28, 2012, 1:59 PM

Post #4 of 14 (95 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

On Tue, Aug 28, 2012 at 2:43 PM, Ricardo Signes
<perl.p5p [at] rjbs>wrote:

> given ($x) {
> when ($y) { ... } # $x ~~ $y
> when (4) { ... } # $x == 4
> when ('4') { ... } # $x eq 4
> }
>
> Deferred/computed values of any sort mean smart match.
>
> Two dead-simple special cases: Numeric literals mean ==. String literals
> mean
> eq.
>

I agree this solves many of the technical issues raised, but I fear that
it's going to confuse some people or mis-set expectations.

* Currently when() does smartmatch, so you have to retrain people not to
think of when() as smartmatch, but to think of when() as a "smart switch"
or something.

* You can test a value with when() that you can't smartmatch, so if people
don't internalize that when() is no longer smartmatch, at some point
they'll smartmatch a literal and expect it to work like when.

Since smartmatching a literal isn't ambiguous, I think that it would be
less confusing to just add literals to the smartmatch table and let when()
stay as smartmatch. That means *one* big change instead of two.

FWIW, I would still like "when {...} {...}" as a shorter way to write "when
(sub{...}) {...}", but think that's "nice to have" and not necessary for
fixing smartmatch.

David

--
*David Golden* <dagolden [at] cpan>
*Take back your inbox!* → http://www.bunchmail.com/
Twitter/IRC: @xdg

perl.p5p at rjbs

Aug 28, 2012, 2:03 PM

Post #5 of 14 (98 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

* David Golden <dagolden [at] cpan> [2012-08-28T16:59:46]
> FWIW, I would still like "when {...} {...}" as a shorter way to write "when
> (sub{...}) {...}", but think that's "nice to have" and not necessary for
> fixing smartmatch.

Note that because we got rid of left-hand-side overloads for ~~, when{}{} can
now be a non-sub block.

--
rjbs

Attachments:

signature.asc (0.48 KB)

doy at tozt

Aug 28, 2012, 2:06 PM

Post #6 of 14 (94 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

On Tue, Aug 28, 2012 at 04:59:46PM -0400, David Golden wrote:
> On Tue, Aug 28, 2012 at 2:43 PM, Ricardo Signes
> <perl.p5p [at] rjbs>wrote:
>
> > given ($x) {
> > when ($y) { ... } # $x ~~ $y
> > when (4) { ... } # $x == 4
> > when ('4') { ... } # $x eq 4
> > }
> >
> > Deferred/computed values of any sort mean smart match.
> >
> > Two dead-simple special cases: Numeric literals mean ==. String literals
> > mean
> > eq.
> >
>
> I agree this solves many of the technical issues raised, but I fear that
> it's going to confuse some people or mis-set expectations.
>
> * Currently when() does smartmatch, so you have to retrain people not to
> think of when() as smartmatch, but to think of when() as a "smart switch"
> or something.

To be fair, this isn't currently true at all - when is very much a
"smart switch". Consider the behavior of "when (qr/a/ && sub { ... })",
for instance.

> * You can test a value with when() that you can't smartmatch, so if people
> don't internalize that when() is no longer smartmatch, at some point
> they'll smartmatch a literal and expect it to work like when.
>
> Since smartmatching a literal isn't ambiguous, I think that it would be
> less confusing to just add literals to the smartmatch table and let when()
> stay as smartmatch. That means *one* big change instead of two.

I think people will have fewer reservations about accepting weird
special cases like this for a keyword-based control structure
(especially considering the precedent set by while (<>), etc) than for
an infix operator (since it will be a weird special case either way -
"why can i do '$foo ~~ 1', but not '$a = 1; $foo ~~ $a'?".

> FWIW, I would still like "when {...} {...}" as a shorter way to write "when
> (sub{...}) {...}", but think that's "nice to have" and not necessary for
> fixing smartmatch.

I think it's a relatively minor gain, for a larger cost in complexity.

-doy

dagolden at cpan

Aug 28, 2012, 3:52 PM

Post #7 of 14 (98 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

On Tue, Aug 28, 2012 at 5:06 PM, Jesse Luehrs <doy [at] tozt> wrote:

> I think people will have fewer reservations about accepting weird
> special cases like this for a keyword-based control structure
> (especially considering the precedent set by while (<>), etc) than for
> an infix operator (since it will be a weird special case either way -
> "why can i do '$foo ~~ 1', but not '$a = 1; $foo ~~ $a'?".
>
>
The opportunity for confusion exists either way. My suggestion is to
change *one* thing -- smartmatch -- instead of *two* things -- smartmatch
and when.

Then all people have to know/relearn is the smartmatch table, not the
smartmatch table *and* the special case rules for when.

David

--
*David Golden* <dagolden [at] cpan>
*Take back your inbox!* → http://www.bunchmail.com/
Twitter/IRC: @xdg

doy at tozt

Aug 28, 2012, 4:02 PM

Post #8 of 14 (95 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

On Tue, Aug 28, 2012 at 06:52:35PM -0400, David Golden wrote:
> On Tue, Aug 28, 2012 at 5:06 PM, Jesse Luehrs <doy [at] tozt> wrote:
>
> > I think people will have fewer reservations about accepting weird
> > special cases like this for a keyword-based control structure
> > (especially considering the precedent set by while (<>), etc) than for
> > an infix operator (since it will be a weird special case either way -
> > "why can i do '$foo ~~ 1', but not '$a = 1; $foo ~~ $a'?".
> >
> >
> The opportunity for confusion exists either way. My suggestion is to
> change *one* thing -- smartmatch -- instead of *two* things -- smartmatch
> and when.
>
> Then all people have to know/relearn is the smartmatch table, not the
> smartmatch table *and* the special case rules for when.

But this *is* a change to when, that's what I'm saying. From perlsyn:

Exactly what the EXPR argument to "when" does is hard to describe
precisely, but in general, it tries to guess what you want done.
Sometimes it is interpreted as "$_ ~~ EXPR", and sometimes it does
not. It also behaves differently when lexically enclosed by a
"given" block than it does when dynamically enclosed by a "foreach"
loop. The rules are far too difficult to understand to be described
here. See "Experimental Details on given and when" later on.

For instance, currently "when ($a && $b)" means
"when ($_ ~~ $a && $_ ~~ $b)".

-doy

perl.p5p at rjbs

Aug 28, 2012, 4:08 PM

Post #9 of 14 (98 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

* David Golden <dagolden [at] cpan> [2012-08-28T18:52:35]
> On Tue, Aug 28, 2012 at 5:06 PM, Jesse Luehrs <doy [at] tozt> wrote:
>
> > I think people will have fewer reservations about accepting weird
> > special cases like this for a keyword-based control structure
> > (especially considering the precedent set by while (<>), etc) than for
> > an infix operator (since it will be a weird special case either way -
> > "why can i do '$foo ~~ 1', but not '$a = 1; $foo ~~ $a'?".
> >
> >
> The opportunity for confusion exists either way. My suggestion is to
> change *one* thing -- smartmatch -- instead of *two* things -- smartmatch
> and when.

That's not quite true. No matter what we're changing both. Right now, when
has many special cases that are not smartmatch: perldoc perlsyn and search for
"Most of the power"

> Then all people have to know/relearn is the smartmatch table, not the
> smartmatch table *and* the special case rules for when.

This is true, though, if when has no special cases, and the way we change it is
to remove them all, leaving only "when ($smartmatch_rhs)"

I think there are merits to both that and to the way I proposed it. I feel
very strongly about the specific example that Jesse L. provided above. I want
to write some code and see what it looks like...

--
rjbs

Attachments:

signature.asc (0.48 KB)

dagolden at cpan

Aug 28, 2012, 6:50 PM

Post #10 of 14 (86 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

On Tue, Aug 28, 2012 at 7:02 PM, Jesse Luehrs <doy [at] tozt> wrote:
> For instance, currently "when ($a && $b)" means
> "when ($_ ~~ $a && $_ ~~ $b)".

/me facepalm

--
David Golden <dagolden [at] cpan>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

demerphq at gmail

Aug 28, 2012, 11:58 PM

Post #11 of 14 (86 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

On 29 August 2012 03:50, David Golden <dagolden [at] cpan> wrote:
> On Tue, Aug 28, 2012 at 7:02 PM, Jesse Luehrs <doy [at] tozt> wrote:
>> For instance, currently "when ($a && $b)" means
>> "when ($_ ~~ $a && $_ ~~ $b)".
>
> /me facepalm

You aren't the only one.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

abigail at abigail

Aug 29, 2012, 1:43 AM

Post #12 of 14 (86 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

On Tue, Aug 28, 2012 at 06:02:33PM -0500, Jesse Luehrs wrote:
> On Tue, Aug 28, 2012 at 06:52:35PM -0400, David Golden wrote:
> > On Tue, Aug 28, 2012 at 5:06 PM, Jesse Luehrs <doy [at] tozt> wrote:
> >
> > > I think people will have fewer reservations about accepting weird
> > > special cases like this for a keyword-based control structure
> > > (especially considering the precedent set by while (<>), etc) than for
> > > an infix operator (since it will be a weird special case either way -
> > > "why can i do '$foo ~~ 1', but not '$a = 1; $foo ~~ $a'?".
> > >
> > >
> > The opportunity for confusion exists either way. My suggestion is to
> > change *one* thing -- smartmatch -- instead of *two* things -- smartmatch
> > and when.
> >
> > Then all people have to know/relearn is the smartmatch table, not the
> > smartmatch table *and* the special case rules for when.
>
> But this *is* a change to when, that's what I'm saying. From perlsyn:
>
> Exactly what the EXPR argument to "when" does is hard to describe
> precisely, but in general, it tries to guess what you want done.
> Sometimes it is interpreted as "$_ ~~ EXPR", and sometimes it does
> not. It also behaves differently when lexically enclosed by a
> "given" block than it does when dynamically enclosed by a "foreach"
> loop. The rules are far too difficult to understand to be described
> here. See "Experimental Details on given and when" later on.
>
> For instance, currently "when ($a && $b)" means
> "when ($_ ~~ $a && $_ ~~ $b)".
>

Yeah, but "when (2 && 3)" does *NOT* mean

when ($_ ~~ 2 && $_ ~~ 3)

as '2 && 3' gets constant folded:

$ perl -MO=Deparse -E 'given ($_) {when (2 && 3) {say}}'
use feature 'current_sub', 'evalbytes', 'fc', 'say', 'state', 'switch', 'unicode_strings', 'unicode_eval';
given ($_) {
when (3) {
say $_;
}
}
-e syntax OK
$

Which, IMO, is a misfeature of a (mis?)feature.

Abigail

perl.p5p at rjbs

Aug 31, 2012, 7:42 AM

Post #13 of 14 (85 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

* Peter Rabbitson <rabbit-p5p [at] rabbit> [2012-08-29T09:00:47]
> My 2c on this last point. The fact that you are having the same discussion
> repeatedly over the course of a year indicates that the definition of this
> feature does not "collapse" to a straightforward set of semantics, no matter
> how many times you reexamine it. Combine this with the general drive to make
> perl5 *less* ambiguous - and all of a sudden FC's suggestion seems the
> sanest of all so far.

So far, my entire experience has been that it *does* collapse into a
straightforward set of semantics. I proposed them in 2011 and again in 2012.
The discussion has largely been "let's add more cases," but those fail under
the weight of their complexity.

So, I don't think the current ~~/when proposal introduces serious ambiguity. I
think if it gets rejected, it will be because its simplicity ends up meaning it
brings too little utility to the table for the cost.

I certainly do agree with the implicit suggestion that it would be insane to be
having this discussion again in 2013. ;)

--
rjbs

Attachments:

signature.asc (0.48 KB)

rabbit-p5p at rabbit

Aug 31, 2012, 8:02 AM

Post #14 of 14 (86 views)
Permalink

Re: fixing smartmatch (again (still)) [In reply to]

Interesting, my mail to the list itself got eaten... anyway

On Fri, Aug 31, 2012 at 10:42:05AM -0400, Ricardo Signes wrote:
> * Peter Rabbitson <rabbit-p5p [at] rabbit> [2012-08-29T09:00:47]
> > My 2c on this last point. The fact that you are having the same discussion
> > repeatedly over the course of a year indicates that the definition of this
> > feature does not "collapse" to a straightforward set of semantics, no matter
> > how many times you reexamine it. Combine this with the general drive to make
> > perl5 *less* ambiguous - and all of a sudden FC's suggestion seems the
> > sanest of all so far.
>
> So far, my entire experience has been that it *does* collapse into a
> straightforward set of semantics. I proposed them in 2011 and again in 2012.
> The discussion has largely been "let's add more cases," but those fail under
> the weight of their complexity.

This is so much like US congress ;)))

> So, I don't think the current ~~/when proposal introduces serious ambiguity. I
> think if it gets rejected, it will be because its simplicity ends up meaning it
> brings too little utility to the table for the cost.

I do not feel this is actually the spirit of this thread. If indeed all we
are still talking about is this:

> ## The New ~~ Operator
>
> $a $b Meaning
> ======= ======= ======================
> Any undef ! defined $a
> Any ~~-overloaded ~~ overloading is used
> Any Regexp, qr-ol $a =~ $b
> Any CodeRef, &{}-ol $b->($a)
> Any Any fatal

Then perhaps it would be beneficial to start *yet another* thread to
explicitly solicit votes on the utility of such a change, with *no*
modifications. A "take it or leave it" call for ++ or --.

In case this thread doesn't materialize, my yet another 2c on this issue
alone: For me personally having an extra operator to service the above table
is madness, but then again I feel the same about the utility of //=

>
> I certainly do agree with the implicit suggestion that it would be insane to be
> having this discussion again in 2013. ;)

Right, and I am glad we are on the same page here. Regardless of the
technical merits, please, by all means, whatever happens, do not give up
until some sort of way moving forward is actually enacted (just agreeing on
something is not sufficient on p5p).

rjbs++

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads