I read Allison's topicalization piece:
http://www.perl.com/pub/a/2002/10/30/topic.html
I started with a simple thought:
is given($foo)
seems to jar with
given $foo { ... }
One pulls in the topic from outside and
calls it $foo, the other does the reverse --
it pulls in $foo from the outside and makes
it the topic.
On its own this was no big deal, but it got
me thinking.
The key thing I realized was that (naming)
the invocant of a method involves something
very like (naming) the topic of a method,
and ultimately a sub and other constructs.
Thus it seems that whatever syntax you pick
for the former is likely to work well for
the latter.
Afaik, the syntax for invocant naming is:
method f ($self : $a, $b) { ... }
But whatever it is, I think one can build
on it for topic transfer / naming too in a
wide range of contexts.
With apologies for talking about Larry's
colon, something that really does sound
like it is taboo for good reason, I'll
assume the above invocant naming syntax
for the rest of this email.
So, perhaps:
sub f ($a, $b) is given($c) { ... }
sub f ($a, $b) is given($c is topic) { ... }
sub f ($a, $b) is given($_) { ... }
could be something like:
sub f ($c : $a is topic, $b) { ... }
sub f ($c : $a, $b) { ... }
sub f ($_ : $a, $b) { ... }
where the first arg to be mentioned is the
topic unless otherwise specified.
(The first line of the alternates is not
semantically the same as the line it is a
suggested replacement for, in that the
current scheme would not set the topic --
its value would be the value of $_ in
the lexical block surrounding the sub
definition. It's not obvious to me why
the current scheme has it that way and
what would best be done about it in the
new scheme I suggest, so I'll just move on.)
Anyhow, the above is my suggestion for an
alternate to 'is given' in a sub definition.
The obvious (to me) thing to do for methods
is to have /two/ colon separated prefixes of
the arg list. So one ends up with either one,
two, or three sections of the arg list:
# $_ is invocant:
method f ($a, $b) { ... }
# $_ and $self are both invocant:
method f ($self : $a, $b) { ... }
# $_/$self are invocant, $c caller's topic
method f ($self : $c : $a, $b) { ... }
One could have incantations such as:
method f ($self : $c : $a is topic, $b) { ... }
method f ($self : $c is topic : $a, $b) { ... }
method f ($self : $_ : $a, $b) { ... }
which all clobber the invocant being 'it',
but if that's what a method author wants,
then so be it.
One question is what happens if one writes:
method f (: $c : $a, $b) { ... }
Is the invocant the topic, or $c, ie what
does a missing invocant field signify?
Jumping to a different topic for one moment,
I think it would be nice to provide some
punctuation instead of (or as an alternate
to) a property for setting 'is topic'. Maybe:
method f ($self : $c : $a*, $b) { ... }
or maybe something like:
method f ($self : $c : $aT, $b) { ... }
(Unicode TM for Topic Marker? Apologies if I
screwed up and the TM character comes through
as something else.)
Anyhow, a further plausible tweak that builds
on the above colon stuff is that one could
plausibly do:
sub f ($bar : $a, $b) {
...
}
and then call f() like so:
f (20 : 30, 40)
as a shortcut for setting $_ before calling f(),
ie to set $_ in the body of f to 20, $a to 30.
Unfortunately that conflicts with use of colon
as an operator adverb. Conclusion: if y'all
end up using a different syntax for specifying
the variable name of the invocant for a method,
and go with the extension I suggested earlier
for replacing 'is given', then maybe the above
can still work, and maybe it would be a good
idea to allow it.
And if you do, I can see a further trick being:
given $foo {
# $_ = $foo here, hiding outer topic
}
given $c : $foo {
# $_ = $foo here, hiding outer topic
# $c = outer $_
}
And likewise for other topicalizers.
--
ralph
