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

Re: given/when/~~ "final" thoughts (ha ha ha)

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
September 26, 2012 18:25
Subject:
Re: given/when/~~ "final" thoughts (ha ha ha)
Message ID:
20120927012524.GB8321@fernweh.plasmasturm.org
* Jesse Luehrs <doy@tozt.net> [2012-09-27 00:35]:
> On Thu, Sep 27, 2012 at 12:29:26AM +0200, Aristotle Pagaltzis wrote:
> > * Father Chrysostomos <sprout@cpan.org> [2012-09-17 02:15]:
> > > Making it work wouldn’t be hard. That would also make lexicals
> > > visible, as in when{my $x}{$x}. I can’t say I’m very fond of the idea.
> > > But I am not opposed to it per se.
> >
> > I think it has to work, actually:
> >
> >     if   ( my $x = foo $bar ) { do_something_with $x }
> >     when { my $x = foo $bar } { do_something_with $x }
>
> The trouble is that the initial concept for "when { ... }" was that it
> was simply syntactic sugar for "when(sub { ... })". Moving away from
> that may end up making things more complicated, conceptually.

And then came the digression about special-casing `when ({ ... })` into
`when (sub { ... })` and then Damian said why the parentheses, no other
block-bearing construct in Perl allows let alone requires them, and then
the proposal came up that it should basically be a `do {}` block. IMO
that should carry over to its mental model.

In any case, we have three options here:

1. Just let it work the minimal way and let it surprise programmers who
   expect `when {/(.)/} { say $1 }` to work, on the grounds that it has
   the semantics you should really be expecting from everywhere else.

2. Add warnings to warn programmers before they get bitten.

3. Make it Just Work.

Note that both case 2 requires adding code specifically to detect this
case, but what it does then is not make the thing work that we know the
programmer wanted, but tell the programmer he can’t do that. Personally
I hate it when my computer says “I know exactly what you wanted and
I could easily do it for you but I’ll be a stickler for rules” (which
can mean “I’ll make you say it the right way instead” or “I’m saying you
shouldn’t be doing it that way” or whichever).


Note also that both options #1 and #2 require the code to be written
something like

    my $x;
    when { $x = foo $bar } { do_something_with $x }

or worse, in the case of captures,

    my $c1;
    when { /(.)/ ? ( $c1 = $1, 1 ) : 0 }  { ... }

Now is there any benefit from that inconvenience other than some notion
of consistency? I may be mistaken, but I cannot think of any reason that
this would be broken or the cause for surprise.

And I don’t think that is for lack of imagination. Because, and this
also goes for whether this inconsistency is greatly bothersome, note
that we also have cross-block scope sharing in at least one key part of
the language:

    if ( my $x = foo $bar ) { do_something_with $x }
    else                    { do_something_else_with $x }

(Likewise for `elsif` blocks.)

There is also this rather more obscure case:

    while ( my $line = <> ) { ... }
    continue { log $line }

I’m sure I’m forgetting another one or two less conspicuous specimens.

In all these cases, no harm nor foul from the scope sharing has been
experienced in practice. It’s just an ugly solution. We’re not Perl 6,
so we do not have the supporting surrounding design principles in place
to fix the lack of beauty. But that seems to me no reason to make the
programmer jump through onerous hoops that we do not impose elsewhere –
even if that means we have to take on another unfortunate exception.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

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