HaloO,
Luke wrote:
> Isn't the point of lexical scoping so that you don't have to worry
> whether somebody else called something the same thing you did? I can
> picture this:
>
> multi combine (Any $x, Any $y) { ZCombinator.new($x, $y) }
> multi combine (@x, @y) { ZList.new([ @x, @y ]) } # concat
> multi combine (Str $x, Str $y) { ZStr.new($x ~ $y) }
Ohh, is the bare multi special form now valid syntax?
> Clearly the author of process intended that two integers get added and
> anything else dies. He was not aware of the combine defined many many
> lines above. But he was smart and made his multis lexically scoped
> so he didn't have to worry.
>
> Really, he should have written process like so:
>
> sub process($x, $y) {
> my sub combine ($a, $b) {...}
> my multi combine (Any $a, Any $b) { die "Cannot combine" }
> my multi combine (Int $a, Int $b) { $a + $b }
>
> return combine($x, $y);
> }
Wouldn't using 'multi sub' allow to drop the first sub,
and override outer symbols 'combine' while a 'multi method'
would augment the inner view of future dispatches with the
inner targets?
> It seems fairly natural when we go with the extension mechanism that
> A12 seems to propose. "multis extend, subs mask", so if you want to
> mask, you just define it as a sub first. It's a little awkward, but
> it'll do. The other way, however, is not nearly as natural:
I would interpret it as "methods are dispatched, subs are called" ---
and "slots are retrieved", but the latter is another subject...
> # let's say that he wanted process() to do what I said he didn't intend
> sub process($x, $y) {
This depends on his intentions to be inclusive or exclusive ;)
> my multi combine (Any $x, Any $y) { OUTER::combine($x, $y) }
> my multi combine (Int $x, Int $y) { $x + $y }
> ...
> }
The combine(Int,Int) target as a method insures the closest match
for two Ints and the combine(Any,Any) insures the presence of a default.
But multi method targets "between" (Int,Int) and (Any,Any) are *not*
excluded, right?
> I guess I'm really arguing for masking by default instead of extention
> on the grounds of the principle of least surprise.
Me too, but with a different syntax by using either a Method or a Sub
type in the multi special form. Hmm, this immediately raises the question:
"Which form gets the default?". I guess it's undecidable in general and
thus a task for a pragma like 'use multi :sub' or some such.
> I also like to think of names as concepts, such that
> if you're extending the concept, you ought to rename it.
I disagree in so far as a concept like the open/close pair is
usefull for very different types of things. And as such these
perfect names shouldn't be blocked for ::Door just because they
are already used by ::IO.
TSa
