Larry Wall wrote:
Dave Whipp wrote:
: A slightly tangental thought: is the behavior of C<given> with no block
: defined? I.e. is

It would be illegal syntax currently.

As I understand it, the proposal is to say that if the parser finds a
';' where it was expecting to find a control block, it treats the rest
of the current block as the expected control block - or something to
that effect.  Eh... messy, and with no substantial gain.

: given $foo { when 1 {...} };
: equivalent to
: given $foo;
: when 1 {...};

Both of these suggestions would seem to duplicate the existing construct:

    $_ = $foo;


Agreed.  But I think that postfix:<?> is rather clean:

   when 1 {...}

Two catches:

1. I could easily define postfix:<?> myself, save for one thing: what
would I put as the parameter for the 'is equiv' trait, so that it has
terminator precedence?

2. 'when' implicitly leaves its current block after successfully being
executed (as per 'last'), since it's designed primarily for use as one
of a set of mutually-exclusive options.  I'm not sure how wise of a
decision that is, since it's easier to add a "last" to a block that
implicitly lacks one than it is to remove a "last" from a block that
implicitly includes one.  Part of me would strongly prefer that "when
$x { ... }" be exactly equivalent to "if $_ ~~ $x { ... }", except for
the inability to append an else block to the former.

Of course, now someone will argue that unary:<=> should assign to $_ by
default, in which case we'd have to find a new iteration operator...

Horrors, no!  '=$filehandle' works just fine for reading an iterator,
thank you...

I _might_ flirt with the idea of postfix:<=> being equivalent to a
filehandle's '.say' method (i.e., writing to an iterator) - or not.
Given the mandatory whitespace that a postfix operator imposes on an
equivalent infix operator, I'd strongly suggest that good practice for
Perl 6 would be to avoid defining both forms if at all reasonable; and
infix:<=> definitely has the edge here.  (Rule of thumb: if you can
avoid doing something that will mandate or forbid whitespace, avoid

Jonathan "Dataweaver" Lang

Reply via email to