On Thu, Feb 28, 2002 at 04:12:12PM -0800, Austin Hastings wrote:
>
> Nobody has the least bit of trouble understanding that WITHIN the for
> loop, the "default value" just changed from whatever it was outside.
Well, C<for> is a topicalizer, and always has been, even before we had a
name for it, so this makes sense.
> 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... :-)
It's true, anything can be taught, but some more easily than others.
> > But however it's done, I want it to be consistent in the bigger
> > picture.
>
> Consistent how?
"Consistent in the bigger picture" i.e. when it is decided how to solve
this, I want to be able to use the same solution in other places, not
just with C<when>.
> I assume you're willing to keep the "is default" idea. (Visions of
> millions of perl hacks with torches and pitchforks here...)
I have no intention of banishing "is default". With or without the
pitchforks. ;) I want to make it more powerful.
> So what's inconsistent? I think that making the "is default" value
> inside the C<when> match the the topic *is* consistent. It scans.
It's an internally consistent idea, and it works. But it doesn't solve
the whole problem.
> 1- Don't use $_ as the default, use $$topic.
> ("why would we want to do that?!?!")
Because, theoretically, the topic is the most important bit of info at
the moment, so of course it's what you want to operate on. $_ is
sometimes the most important bit of info, but sometimes it's just
leftover and hanging around from some previous chunk of code.
> 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.
Yes, whatever the final solution is, it needs to be easy to predict and easy
to control what the current default is.
Lots of interesting ideas. I'm holding out for something better. I don't
know exactly what yet, but I trust Larry.
Allison
--
"This time it was right, it would work, and no one would have to get
nailed to anything."
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
