--- 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