On Mon, Jul 11, 2005 at 04:50:56PM -0400, Matt Fowles wrote:
: Yay! I guess I will take this moment to resuggest @^ as a list of
: invocants and $^ =:= @^[0]. I like how the ^ kinda points you the
: right way, also visually distinctive and doesn't get in the way of
: $_...
I don't see much use for @^ since multis require you to declare all
your invocants anyway. Maybe one could envision a macro that has an
unhealthy interest in innards of an unknown argument list, but that
can probably be better satisified with @?ARGS or some such.
And $^ is just too long to be a standard shortcut.
{
let $Larry.decisive = 1;
Okay, this is what we're gonna do. We're gonna go back pretty close to
where we were originally, but with a twist. That is, .foo is always
a call on the current topic, but the invocant is (again) always the
topic in the outer scope of a method. The difference from before
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
(If necessary we can also compile .foo inside methods down to code
that checks at runtime whether $_ has diverged from $?SELF and pitch
a run-time fit for those situations we can't detect at compile time.
Or we can just declare it erroneous.) Basically, you can't use .foo
inside a "given" or a "for" inside a method.
That's the default, and I'm not changing my mind ever again, at least
till next week. That being said, if you mutate your language with
anything like:
use self "this";
use self "self";
use self "o";
use self "./";
use self "";
...
then the pragma is allowed to warp .foo semantics to make it *always*
refer to $_ everywhere, provided it *also* undoes the default binding
of $_ := $?SELF, so people that people aren't tempted to use .foo to
mean $?SELF.foo in that scope.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
Shame on you. Move the common code to a role, or a base class.
I think the lesson of the last few months is that there are some
things we'll never agree on, and we just need to make it possible
to disagree in the least disagreeable fashion. I've tried hard
to believe everyone's viewpoint on this at one point or another,
so I think I'm qualified to say that they all have their strong
points and their weak points. And that the programmer needs to
have the final say on which viewpoint they find least repulsive.
}
Larry
