Re: proposal: when-blocks, and binding $_

2002-02-27 Thread Austin Hastings

It's amazing what a night will do. See bottom.

--- Allison Randal <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 26, 2002 at 02:20:48PM -0800, Brent Dax wrote:
> > Austin Hastings:
> > #
> > # Which, then, would you like:
> > #
> > # To implicitly localize $_, losing access to an outer version,
> > # or to have to change between implicit and explicit operations?
> 
> Well, I like the idea of having C and the C operate on
> the
> same thing. But I don't really want C to either localize or
> clobber $_, I want it to leave the information structure alone.
> That's
> why I'd alias $_ at the C or the C, just like I would
> now.
> 

BTW, C doesn't alias $_ always. That's why things like the example
below are possible. 

> > # for @A {
> > #   for @B -> $x {
> > # when /a/ { s/x/y/; }
>   s/x/y/;
> > #   }
> > # }
> > #
> > # What should that do?
> 
> Even if we give C aliasing powers, it is still confusing,
> because
> you jump back and forth between the $_ within the C block and
> the
> $_ between C blocks.

Hmm. Suppose we force C to alias $_, but give the coder one
chance to "save" the value:

for @A {
  for @B -> $x {
when /a/ $_ -> $a { s/a/b/; ... $a ...; }
  }
}

Once we get inside the curlies, $_ is aliased to the localized var for
the C (in this case, $x).

And if you've been sufficiently verbose elsewhere,

for @A -> $y {
  for @B -> $x {
when /a/ { s/a/b/; ... $y ... ; }
  }
}

there's no need.

=Austin

__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com



Topicalizers: Why does when's EXPR pay attention to topicalizer regardless of associated variable?

2002-02-27 Thread Garrett Goebel

From: Austin Hastings [mailto:[EMAIL PROTECTED]]
> 
> for @A {
>   for @B -> $x {
> when /a/ $_ -> $a { s/a/b/; ... $a ...; }
>   }
> }
> 
> Once we get inside the curlies, $_ is aliased to the localized var for
> the C (in this case, $x).

I went back and read the Apocolypse 4: RFC 022. I may even understand it
this time through. At least, I no longer have a brain fart when reading the
code above. -Speaking of which, you forgot your trailing semicolon for the
C expression's final closure/block.

Why does C's EXPR pay attention to the topicalizer regardless of
associated variable?

Why introduce the special case? Especially when consistency and
simplification seem to be a strong undercurrent in Perl6? I'm curious what
the reasoning behind the special case is. I don't see what it gives us...
beside one more thing to remember. What would be a use case that illustrates
the need for the special case? And is the special case the common one?

$_ = 'foo';
given 'bar' -> $f {
  if   /foo/ {print};   # true, prints 'foo'
  when /bar/ {print};   # true, prints 'foo'
  when /bar/ -> $g {print}; # true, prints what? 'foo'
}



Ambiguity with regards to switch statements special handling of Class::Name

2002-02-27 Thread Garrett Goebel

Larry Wall wrote:
> I think the switch statement will have to recognize any
> Class::Name known at compile time, and force it to call
> $!.isa(Class::Name).

Don't you mean the case/when statement? Wouldn't you want the following to
work:

for @obj {
  when Dog { ... }
  when Cat { ... }
}




Re: More questions on downwards binding.

2002-02-27 Thread Austin Hastings


--- Larry Wall <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> : More questions on downwards binding,
> : 
> : > for @foo -> $a, $b {  # two at a time
> : > ...
> : > }
> : 
> : Interpretation #1:
> : for @foo[0..$foo:2] -> $a,
> : @foo[1..$foo:2] -> $b
> : { ... }
> : 
> : Interpretation #2:
> : for @foo -> $a { $b := $a; ... }
> : 
> : I like this second one, as a short-cut, but it's not worth it. Am I
> : correct in assuming (as I henceforth shall) that ->(list) is a
> : distributive binding operation, which spreads all the lhs list
> elements
> : into rhs list elements?
> 
> Neither of these is an accurate view of the current design.  The
> 
> -> LIST { ... }
> 
> construct is declaring a closure with a certain parameter signature.
> The construct interpreting that closure (C in this case) is free
> to pass arguments to those parameters however it sees fit.

What's the query or specification mechanism for users? Or are the
constructs going to have built-in semantics which we can't emulate?
(IOW, is there any way for me to know what the expected shape of 
$closure(@_) will be?)

> : ==
> : 
> : Is it legitimate to make the precedence of -> high, and then
> : just require that distributive binding use parens? (Which resonates
> : well with existing usages: my ($arg1, $arg2) = @_;)
> : 
> : for @ary1 -> ($nam1, $pw1, $uid1, $gid1, $gcs1, $dir1, $shl1 ),
> : @ary2 -> ($nam2, $pw2, $uid2, $gid2, $gcs2, $dir2, $shl2)
> : {
> :...
> : }
> 
> Yes, we could do it that way.

I'm for it. 

> : ==
> : 
> : > : What would the default-variable scheme do in this context? 
> : > 
> : > That's a problem.  But a more basic problem is, what would a
> C
> : > do?
> : 
> : Given that comma is a list operator, C takes the last one.
> 
> No, that's Perl 5 thinking.  In Perl 6 the comma always produces a
> list
> even in scalar context.
> 
> : for @a1 -> $a1,
> : @a2 -> $a2
> : {
> : when /Larry Wall/i { ++larrymeter; }; # Uses $a2 implicitly.
> : when $a1 =~ /Perl/ { ... };   # doesn't.
> : }
> 
> It would be more likely to assume a given of any($a1,$a2).

Perl5 is the perl I think now. Sorry.

If the C uses any() as its given context, multiple-binding loops
are going to have to (almost) always specify their comparisons. Not
necessarily a bad thing, even for $_. Although hash iteration won't be
as cool.

for %hash -> ($key, $value) {
  when !defined($value) { delete %hash{$key}; }
}

Instead of

for %hash -> ($key, $value) {
  when undef { delete %hash{$key}; }
}

(The real "dwim" would have based C on the hash key, instead, so
I'm not too upset here... :-)

Will there be an "unless" version of when, for implied negation?
Perhaps special recognition of 'not' in that context, as:

when not Exception { ... }
when not /a/ { ... }
when not @ary { ... }

> : ==
> : > you might not be able to say
> : >  mumble $a -> $b,
> : > $b -> $a
> : >  { ... }
> : > to mean
> : >  mumble $a, $b -> $b, $a
> : >  { ... }
> : 
> : mumble ($a, $b) -> ($b, $a) # Makes a list and distributively binds
> it.
> : { ... }
> : 
> : ===
> : > And I think we have to allow for the case that there are no
> actuals
> : > to bind to the formals yet, which means we need an ordinarly
> looking
> : > parameter list after the ->.  That is, as it currently stands,
> you
> : > can say
> : > my $closure = -> $a, $b { ... }
> : > as an equivalent to
> : > my $closure = sub ($a, $b) { ... }
> : > 
> : > (The only difference being that the latter pays attention to
> "return"
> : > exceptions because it has an explicit "sub".)
> : 
> : How would you invoke such a defun?
> 
> Like any other anonymous subroutine or closure.
> 
> : $closure($a, $b)
> 
> That would work.
> 
> : for @list $closure
> : map $closure @list
> : grep $closure @list
> 
> Probably not.

Why not? While my syntax seems doomed to be wrong, your prior
statements gave me the impression that certain constructs (e.g.,
C) may have closure-interpretation behavior that users would be
hard-pressed to emulate. 

For example, from above:

> : > for @foo -> $a, $b {  # two at a time
> : > ...
> : > }

It would be much easier for me to say

for @foo &$my_closure; # or however this should be written

than 

my @bar ^:= @foo;  # malleable ary with same refs

while @bar {
   my @args;
   ... figure out behavior of $my_closure, set up @args ...
   $my_closure(@args);
}


> 
> : Finally, what does <- do? 
> 
> Numeric comparison of a negated value.  Unless we turn := into <-,
> which
> would probably drive the mathematicians nuts.

As I recall, :- and := have both been introduced as inadequate textual
representations of "<-", so there's some justification there.

And frankly, it's too late for the mathematicians - they're already
nuts. ;->

=Austin



__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://g

Semicolons: where they're needed

2002-02-27 Thread Garrett Goebel

Larry Wall in Apocalypse 4 writes:
> this special rule only applies to constructs that take a
> block (that is, a closure) as their last (or only) argument.
> Operators like sort and map are unaffected. However, certain
> constructs that used to be in the statement class may become
> expression constructs in Perl 6.

Does that mean there may still be constructs which take a block, as their
last argument, but which don't require a semicolon if they can be written as
one-liners?

How terribly unpopular would it be if the "when do I need to use a
semicolon" question was simply answered:

is block-ending construct's final curly on a line by itself ? 0 : 1


And can we assume that "on a line by itself" ignores non-$/ whitespace?



RE: Topicalizers: Why does when's EXPR pay attention to topicalizer r egardless of associated variable?

2002-02-27 Thread Garrett Goebel

From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> Speaking of which, you forgot your trailing semicolon for the
> C expression's final closure/block.

s/expression/statement/



Re: Ambiguity with regards to switch statements special handling of C lass::Name

2002-02-27 Thread Austin Hastings

--- Garrett Goebel <[EMAIL PROTECTED]> wrote:
> Larry Wall wrote:
> > I think the switch statement will have to recognize any
> > Class::Name known at compile time, and force it to call
> > $!.isa(Class::Name).
> 
> Don't you mean the case/when statement? Wouldn't you want the
> following to
> work:
> 
> for @obj {
>   when Dog { ... }
>   when Cat { ... }
> }
> 
To make matters worse, what's the test sequnce?

If I have classes 'X' and 'Y', and a method Y::X, 

my Y $y;

given $y {
  when X { ... }
}

Does that evaluate true (because of $a.$b() rule) or not (because of
$a.isa($b)) rule, or does it try both?

If so, in what order? 

And can we use

when .X { ... }

instead, to make clear that it's a method test and not an isa test?

=Austin




__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com



Re: Nevermind -- Ambiguity with regards to switch statements special handling of C lass::Name

2002-02-27 Thread Austin Hastings


--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> --- Garrett Goebel <[EMAIL PROTECTED]> wrote:
> > Larry Wall wrote:
> > > I think the switch statement will have to recognize any
> > > Class::Name known at compile time, and force it to call
> > > $!.isa(Class::Name).
> > 
> > Don't you mean the case/when statement? Wouldn't you want the
> > following to
> > work:
> > 
> > for @obj {
> >   when Dog { ... }
> >   when Cat { ... }
> > }
> > 
> To make matters worse, what's the test sequnce?
> 
> If I have classes 'X' and 'Y', and a method Y::X, 
> 
> my Y $y;
> 
> given $y {
>   when X { ... }
> }
> 
> Does that evaluate true (because of $a.$b() rule) or not (because of
> $a.isa($b)) rule, or does it try both?
> 
> If so, in what order? 
> 
> And can we use
> 
> when .X { ... }
> 
> instead, to make clear that it's a method test and not an isa test?
> 
> =Austin

'Look further down, idiot!'

The answer to my question is some paras lower. Yes, there's  an order,
and yes, .method is usable.

And yes, I feel foolish. :-O 'doh!

=Austin


__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com



Re: proposal: when-blocks, and binding $_

2002-02-27 Thread Allison Randal

On Wed, Feb 27, 2002 at 08:02:08AM -0800, Austin Hastings wrote:
> 
> BTW, C doesn't alias $_ always. That's why things like the example
> below are possible. 

Yes. C and C will only alias $_ when they are not aliasing a
named variable.

> Hmm. Suppose we force C to alias $_, but give the coder one
> chance to "save" the value:
> 
> for @A {
>   for @B -> $x {
> when /a/ $_ -> $a { s/a/b/; ... $a ...; }
>   }
> }
> 
> Once we get inside the curlies, $_ is aliased to the localized var for
> the C (in this case, $x).

I'm still not convinced of your basic point, that it would be a good
thing to have C aliasing $_. Variations on whether it does it
automatically or at my request and how don't change the fundamental
concept. C is a conditional like C, not a topicalizer.

Allison



Re: Topicalizers: Why does when's EXPR pay attention to topicalizer r egardless of associated variable?

2002-02-27 Thread Austin Hastings


--- Garrett Goebel <[EMAIL PROTECTED]> wrote:
> Speaking of which, you forgot your trailing semicolon
> for the C expression's final closure/block.

I'll claim that when, like if, shouldn't need one. (I'd also normally
use multiple lines, but I'm trying to conserve newlines... :-)
 
> Why does C's EXPR pay attention to the topicalizer regardless
> of associated variable?

Because two contexts (switch/case and CATCH) suggest that as "obvious"
behavior, and C is targeted at those contexts. (CATCH is really a
variation of a switchish theme, but still...)


Example:

given $x % 3 {
  when 0 { ... }
  when 1 { ... }
  when 2 { ... }
  default { print "Surprise!\n"; }
}

for @A {
  fragile();

  CATCH {
when Exception::PEBKAC { ... }
when Exception::NotANumber { ... }
  }
}

=Austin


__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com



Re: Topicalizers: Why does when's EXPR pay attention to topicalizer r egardless of associated variable?

2002-02-27 Thread Allison Randal

On Wed, Feb 27, 2002 at 10:32:24AM -0600, Garrett Goebel wrote:
> 
> Why does C's EXPR pay attention to the topicalizer regardless of
> associated variable?
> 
> Why introduce the special case? Especially when consistency and
> simplification seem to be a strong undercurrent in Perl6? I'm curious what
> the reasoning behind the special case is. I don't see what it gives us...
> beside one more thing to remember. What would be a use case that illustrates
> the need for the special case? And is the special case the common one?
> 
> $_ = 'foo';
> given 'bar' -> $f {
>   if   /foo/ {print};   # true, prints 'foo'
>   when /bar/ {print};   # true, prints 'foo'
>   when /bar/ -> $g {print}; # true, prints what? 'foo'
> }

Why? Because it's oh-so dwim. Think about it, if you've just typed a

given $x { ...
or
given $x -> $y { ...

you know for a fact that you're going to want every C to
compare against the $_ or $y. Why force people to type:

when $y =~ /a/ {...}
when $y =~ /b/ {...}
...

when you already know what they mean? And yes, it's the common case. How
many times do you think you'll have a switch statement and want the case
to compare against some value external to the switch?

$_ = 'foo';
given 'bar' -> $y {
when /a/ {...} 
}

It's counterintuitive for this to translate to "When that foo value
matches /a/ then take an action." If you'd meant that, it would make
alot more sense to do:

given 'foo' {
when /a/ {...} 
}


Allison



Re: proposal: when-blocks, and binding $_

2002-02-27 Thread Austin Hastings


--- Allison Randal <[EMAIL PROTECTED]> wrote:
> I'm still not convinced of your basic point, that it would be a good
> thing to have C aliasing $_. Variations on whether it does it
> automatically or at my request and how don't change the fundamental
> concept. C is a conditional like C, not a topicalizer.

Right, it's a topicalizee, the victim of topicalization. And so it uses
$_ or $x or $! or whatever the current topic is.

But inside, you have to KNOW what the topic is again, you can't just
use the default variable(s), so that differentiation of

for @logged_exceptions -> $e {
  when .survivable { if $e.isa('Exception::PEBKAC') { ... } }
}

versus

CATCH {
  when .survivable { if $!.isa('Exception::PEBKAC') { ... } }
}

becomes necessary. 

What I'm trying to suggest is that C, because it already is doing
some special things (huge list of conditionals to try, implied 'next'),
is an orthogonal code element. It really IS going sideways, and unless
you are coding sideways (using C or C) the when-block
represents a context-switch at the developer level.

To that end C should, when (urg!) used in a loop or other
straight-ahead construct to check the current topic, force the current
topic to become the default.

=Austin


__
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com



RE: Semicolons: where they're needed

2002-02-27 Thread Brent Dax

Garrett Goebel:
# Larry Wall in Apocalypse 4 writes:
# > this special rule only applies to constructs that take a
# > block (that is, a closure) as their last (or only) argument.
# > Operators like sort and map are unaffected. However, certain
# > constructs that used to be in the statement class may become
# > expression constructs in Perl 6.
#
# Does that mean there may still be constructs which take a
# block, as their
# last argument, but which don't require a semicolon if they
# can be written as
# one-liners?
#
# How terribly unpopular would it be if the "when do I need to use a
# semicolon" question was simply answered:
#
# is block-ending construct's final curly on a line by itself ? 0 : 1

Oooh, there's a problem with that concept:

if(foo) {
bar
} #There's a semicolon here...
else {#which leaves this else dangling!
baz
}

# And can we assume that "on a line by itself" ignores non-$/
# whitespace?

And comments, I imagine.

--Brent Dax
[EMAIL PROTECTED]
Parrot Configure pumpking, regex hacker, embedding coder, and boy genius

#define private public
--Spotted in a C++ program just before a #include




Re: proposal: when-blocks, and binding $_

2002-02-27 Thread Allison Randal

On Wed, Feb 27, 2002 at 10:11:13AM -0800, Austin Hastings wrote:
> 
> > C is a conditional like C, not a topicalizer.
> 
> Right, it's a topicalizee, the victim of topicalization. And so it uses
> $_ or $x or $! or whatever the current topic is.

i.e. a "defaulting construct" or "topic sensitive keyword". I like the
latter, in this case, because it expresses what C defaults to.

> But inside, you have to KNOW what the topic is again, you can't just
> use the default variable(s), so that differentiation of
> 
> for @logged_exceptions -> $e {
>   when .survivable { if $e.isa('Exception::PEBKAC') { ... } }
> }
> 
> versus
> 
> CATCH {
>   when .survivable { if $!.isa('Exception::PEBKAC') { ... } }
> }
> 
> becomes necessary. 
> 
> What I'm trying to suggest is that C, because it already is doing
> some special things (huge list of conditionals to try, implied 'next'),
> is an orthogonal code element. It really IS going sideways, and unless
> you are coding sideways (using C or C) the when-block
> represents a context-switch at the developer level.
> 
> To that end C should, when (urg!) used in a loop or other
> straight-ahead construct to check the current topic, force the current
> topic to become the default.

I absolutely agree with the problem you're trying to solve. The "when
..survivable" vs. "if $e.isa..." distinction bothers me as well. But I'm
greedy. I don't want to treat the symptom by adding to the list of ways
that C is weird. I want a systematic solution for the whole
language. To me that means taking a step back from the familiar, but
limiting, concept of "$_ is default". Exactly how that will work out,
defaulting to topic everywhere, flagging the variable with an "assumed"
property, or something else entirely, I'm not sure. But however it's
done, I want it to be consistent in the bigger picture.

Allison



RE: Semicolons: where they're needed

2002-02-27 Thread Garrett Goebel

From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Garrett Goebel:
> # Larry Wall in Apocalypse 4 writes:
> # > this special rule only applies to constructs that take a
> # > block (that is, a closure) as their last (or only) argument.
> # > Operators like sort and map are unaffected. However, certain
> # > constructs that used to be in the statement class may become
> # > expression constructs in Perl 6.
> #
> # Does that mean there may still be constructs which take a
> # block, as their last argument, but which don't require a
> # semicolon if they can be written as one-liners?
> #
> # How terribly unpopular would it be if the "when do I need
> # to use a semicolon" question was simply answered:
> #
> # is block-ending construct's final curly on a line by itself ? 0 : 1
> 
> Oooh, there's a problem with that concept:
> 
>   if(foo) {
>   bar
>   } #There's a semicolon here...
>   else {#which leaves this else dangling!
>   baz
>   }

Really?

Isn't the C's block the one with the final curly in the if/elsif/else
statement?

And throwing caution to the wind... I'm one of the fools that prefers:

if foo {
  1
} elsif bar {
  2 
} else {
  3
}

I don't like lining up your C's and C's with C's because
visually it makes it look like a separate statement (to me). I don't mean to
disgress into matters of taste... but it would certainly be nice if all
constructs with dangling blocks could be expected to follow the same rules.



RE: Topicalizers: Why does when's EXPR pay attention to topicalizer r egardless of associated variable?

2002-02-27 Thread Garrett Goebel

From: Allison Randal
> Garrett Goebel wrote:
> > 
> > Why does C's EXPR pay attention to the topicalizer 
> > regardless of associated variable?
> > 
> > Why introduce the special case?

>
> Why? Because it's oh-so dwim. Think about it, if you've just typed a
> 
>   given $x { ...
> or
>   given $x -> $y { ...
> 
> you know for a fact that you're going to want every C to
> compare against the $_ or $y. Why force people to type:
> 
>   when $y =~ /a/ {...}
>   when $y =~ /b/ {...}
>   ...
> 
> when you already know what they mean? And yes, it's the 
> common case. How many times do you think you'll have a
> switch statement and want the case to compare against
> some value external to the switch?

Not just some value external to the switch, but the value in $_.

I now see the DWIM aspect. Thanks BTW.

But how often will people have non- C statements within a C
scope that'll need the special case handling so they can see a different $_
than C?

To adapt your example:

$hi = 'hello';
$x  = 'burt';
for $hi {
  given $x -> $y {
when /burt/ { print "Go Away" };
default { print };
  }
}

or without the special case:

$hi = 'hello';
$x  = 'burt';
for $hi -> $y {
  given {
when /burt/ { print "Go Away" };
default { print };
  }
}

The second is obviously more explict, but does but requires a few more keys
be typed. I wonder if the C/C special case is really going to
be used regularly enough to justify the loss of clarity, consistency, and
the additional obfuscation potential.

$_ = 'foo';
given 'bar' -> $z {   
  if /foo/ { ... }# true,  $_ = foo
  when 'bar' {# true,  $_ = bar
if /foo/ { ... }; # true,  $_ = foo
  }
  $_ = 'baz'; #$_ = baz
  when 'bud' {# false, $_ = bar
if /baz/ { ... }; # true,  $_ = baz
  }
}


I guess the next question in the context of the following is:

Larry Wall wrote in Apocalypse 4:
> It should be possible to make user-extensible syntax look
> just like built-in syntax. 

How would I create a user-extensible construct that works like given/when?
I'm guessing the answer is: you don't.



RE: Topicalizers: Why does when's EXPR pay attention to topicaliz er r egardless of associated variable?

2002-02-27 Thread Garrett Goebel

Dang... why isn't you see so many more obvious errors, the moment after you
click send?

From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> 
> or without the special case:
> 
> $hi = 'hello';
> $x  = 'burt';
> for $hi -> $y {
>   given {
> when /burt/ { print "Go Away" };
  default { print $y };
  ^^
>   }
> }



Re: Topicalizers: Why does when's EXPR pay attention to topicaliz er r egardless of associated variable?

2002-02-27 Thread Allison Randal

On Wed, Feb 27, 2002 at 04:24:48PM -0600, Garrett Goebel wrote:
> From: Allison Randal
> 
> Not just some value external to the switch, but the value in $_.
> 
> I now see the DWIM aspect. Thanks BTW.
> 
> But how often will people have non- C statements within a C
> scope that'll need the special case handling so they can see a different $_
> than C?

That's exactly what the non- C statements will see currently.

Are you asking the question in the context of Apocalypse 4 or in the
context of the hypothetical "C aliases to $_" discussion? I'll
answer as if the former, because it seems to fit the best, but if you
meant the latter the answer would be slightly different.

I think we're bogged down in the "$_ is default" idea. We really have
two entirely separate defaults, $_ and topic. Sometimes they're the same
and sometimes they're not. Hm... pretend for a moment that there's a
variable $topic (there isn't, but pretend). It's very similar to $_, but
not quite. When you do a

given $x {
...
}

then both $_ and $topic hold the value of $x. But, when you do a

given $x -> $y {
...
}

$topic holds the value of $y (i.e. the value of $x), but $_ doesn't (it
hasn't been affected at all). 

C always defaults to $topic, it doesn't care about $_ (except that
when $topic has no value at all, it will "steal" a value from $_).  But
everything else still defaults to $_, and pays no attention to $topic.
(And remember, there is no $topic, it is merely for illustrating the
existence of the abstract "topic").


So this is what the code would be doing:

> $hi = 'hello';
> $x  = 'burt';
> for $hi {
>   given $x -> $y {
> when /burt/ { print "Go Away" };
  # matches on $y, the topic
> default { print };
  # prints $_, not $y
>   }
> }
> 
> or without the special case:
> 
> $hi = 'hello';
> $x  = 'burt';
> for $hi -> $y {
>   given {
> when /burt/ { print "Go Away" };
> default { print $y};
>   }
> }

The second bit of code (with corrections in place) isn't going to do
what you expect at all because the 

given {
...
}

is an "empty given" which has a special meaning of "make boolean
comparisons". So /burt/ is being compared to "True" (I'm not sure if
this would fail because the regex doesn't match "True", or succeed
because "burt" is a true value, but it wouldn't have anything to do with
$y).
 
> The second is obviously more explict, but does but requires a few more keys
> be typed. I wonder if the C/C special case is really going to
> be used regularly enough to justify the loss of clarity, consistency, and
> the additional obfuscation potential.
> 
> $_ = 'foo';
> given 'bar' -> $z {   
>   if /foo/ { ... }# true,  $_ = foo
>   when 'bar' {# true,  $_ = bar
> if /foo/ { ... }; # true,  $_ = foo
>   }
>   $_ = 'baz'; #$_ = baz
>   when 'bud' {# false, $_ = bar
> if /baz/ { ... }; # true,  $_ = baz
>   }
> }

So these lines are not "$_ = bar" but 

   ...
   when 'bar' {# true,  topic = bar
   ...
   when 'bud' {# false, topic = bar
   ...

I think your more general question boils down to: "Is this whole notion
of topic really worth the effort"? And the confusion about C
actually supports your argument. Perl gurus and newbies alike are going
to have to do a little mental stretching for this one (just a tiny bit).
But I do think it's worth it. Despite the details of consistency and
clarity that still need to be worked out, it's a very dwim change that
is a big part of the elegance of the switch statement.

> I guess the next question in the context of the following is:
> 
> Larry Wall wrote in Apocalypse 4:
> > It should be possible to make user-extensible syntax look
> > just like built-in syntax. 
> 
> How would I create a user-extensible construct that works like given/when?
> I'm guessing the answer is: you don't.

I sure hope you can. I intend to use it.

Allison