> > (naming) the invocant of a method involves
> > something very like (naming) the topic
>
> Generally, there's no conceptual link...
....other than
> The similarity is that both are implicit
> parameters
which was my point.
Almost the entirety of what I see as relevant
in the context of deciding syntax for naming
the invocant is that it's an especially
important implicit argument to methods that
may also be the topic.
Almost the exact same thing is true of the
"topic", with the exception being that it
applies to subs as well as methods.
It's clear you could have come up with
something like one of these:
method f ($a, $b) is invoked_by($self)
method f ($a, $b) is invoked_by($self is topic)
method f ($a, $b) is invoked_by($_)
but you didn't. Any idea why not?
> There are times when it's useful to access
> the caller's topic without setting the current
> topic and times when it's useful to just set
> the current topic.
> ...
> When you have a system with two independent
> but interacting features, it's far more
> efficient to define two independent flags
> than to define 4 flags
Of course. The general scheme I suggested
doesn't impinge on this one way or the other.
But the specifics I suggested made a different
choice for the default situation.
As you said of the current scheme:
The following example will either print
nothing, or else print a stray $_ that is
in lexical scope wherever the sub is defined.
sub eddy ($space, $time) {
print;
}
In the scheme I suggest the first arg is the
topic by default (just as is the case for the
other topicalizers such as pointy sub, for,
etc in the current scheme). I think this
choice makes sense, but then, as I implied,
maybe I'm missing something.
> > method f ($self : $c : $a*, $b) { ... }
(where * is short for 'is topic'.)
> Is this really common enough to merit a single
> punctuation character?
If I didn't think so I wouldn't have suggested
the shortcut. ;>
> > Anyhow, a further plausible tweak that builds
> > on the above colon stuff is that one could
> > plausibly do:
>
> So, in this system, the colon is used for both
> explicit parameters and implicit parameters.
> ...
> I'd prefer more consistency.
If by "system" you mean the scheme I suggested
prior to this "plausible tweak", then no. The
colon would only be used in this way if one
introduced the tweak. Rejecting this tweak has
no impact on the value of the general scheme
I suggested.
The colon in my scheme (not the tweak) can
optionally be used to be explicit in sub
*defs* about otherwise implict args. The
tweak I am suggesting is that one could,
optionally, use the exact same syntax to
be explicit in sub *calls* about otherwise
implicit args. I think this has a clean
consistency.
> > given $c : $foo {
> > # $c = outer $_
> > }
>
> It would be much more transparent to simply
> name the outer topic.
How is this so different to
method f ($c : $foo) {
# $c = invocant
}
?
>
> Allison
--
ralph
