On Tue, Oct 25, 2005 at 02:51:35PM +0200, Juerd wrote:
: For comparison, here is the same code snippet again. First with, and
: then without explicit $_.
: With:
:     given ($subject) -> $_ {
:         $_ ~~ s/foo/bar/;
:         $_++;
:         $_ x= 2;
:         $_ ~= "!";
:     }
: Without:
:     given ($subject) {
:         s/foo/bar/;

Already the default.

:         ++;

Can already use .++ there.  That's because you can already use . on
any postfix operator, and since any . form defaults to $_, you get
.++ for free.  I'll let you have .-- as well.  And .! if you define
factorial.  :-)

It would be possible to extend . to allow any infix plus its right argument
to be treated as a postfix, presuming there wasn't already a postfix of
that name.  However...

:         x= 2;

That might validly parse as assignment to an lvalue sub: x() = 2;
Unfortunately .x= 2 doesn't work either, since we also have lvalue
methods.  Actually, x=2 should parse as x(=2), since a list operator
always expects a term next.  Yes, we *could* throw all the infix
operators into the prefix pot and match them under longest-token, but
the basic problem with the proposal is rampant term/operator confusion.
What should the lexer do when it sees a statement starting with


Those could get away with

    ./= 2
    .%= 2
    .*= 2
    .+= 22

But then you're only saving a character (and maybe a space) over $_.

:         ~= "!";

That would validly parse as


: I think the latter is more elegant, without reducing legability or
: maintainability. I also think that the code is immediately obvious, even
: to people coming from Perl 5, who never read this thread.

I think you're relying on those people using whitespace to dwym,
but unfortunately people chunk things differently from computers.
And most people will be uncomfortable if the computer uses whitespace
to guess, more so because it's doing lookahead to find that whitespace.
And are you ready to disallow patterns that start with '='?

And basically I don't think people want to mutate $_ with math operators
all that often--and if they do want to, they probably don't.  :-)


Reply via email to