--- Allison Randal <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 27, 2002 at 10:11:13AM -0800, Austin Hastings wrote:
> >
> > > C<when> is a conditional like C<if>, 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<when> defaults to.
okay, "tsk" it 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<when>, 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<given> or C<CATCH>) the when-block represents a context-switch
> > at the developer level.
> >
> > To that end C<when> 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<when> is weird.
Which is why I think it's reasonable for the same rule that applies to
"for" in perl5 to apply here:
for (@ary) { print; }
Nobody has the least bit of trouble understanding that WITHIN the for
loop, the "default value" just changed from whatever it was outside.
Likewise:
when .survivable { print; }
to me is obvious. (Or at least could become obvious by the time I
finished reading the v.6 camel book... :-)
> 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.
Consistent how? I assume you're willing to keep the "is default" idea.
(Visions of millions of perl hacks with torches and pitchforks here...)
So what's inconsistent? I think that making the "is default" value
inside the C<when> match the the topic *is* consistent. It scans.
My notion is that having that change take place and
_losing_access_to_data_ is wrong. So:
2- Give me one last chance to save away or alias $_.
(Uniformly amivalenegative reaction, but it did put the onus and the
performance issues on the developer.)
-or-
1- Don't use $_ as the default, use $$topic.
("why would we want to do that?!?!")
Either way C<when> can do the right thing and perform a "source context
switch" while not restricting my access to the data I may have had
current outside the block.
Of course, #1 means there needs to be a way of figuring out what the
current topic is, which tends to either add function calls or circle us
back around to $_ (or some other line noise var) once again.
How about this: whenever $_ is superseded by a topic, the old value
gets shifted/pushed into @__ (two underscores). If you want it, it's
there. If you don't, it gets quietly unshifted/popped in a few moments.
Or this: $_ is always the current topic, but $__ is a ref to the last
$_ in case you want to get it.
Or this: $_ is always the current topic, but $. is the current 'point',
and usually $. := $_, except when topicalized.
Frankly, my big concern is that there are (at least in perl5) a lot of
places where variables are prescribed. map, sort, grep come immediately
to mind. As long as I get one chance to rescue those data bits, I don't
care if nested C<when>s rewrite each other's topics or push them on a
stack or store them in the caller() or whatever.
=Austin
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
