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.


Reply via email to