develooper Front page | perl.perl6.language | Postings from September 2005

RE: multi scoping

Thread Previous | Thread Next
Thomas Sandlass
September 5, 2005 02:53
RE: multi scoping
Message ID:

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) {$x, $y) }
>    multi combine (@x, @y)         {[ @x, @y ]) }   # concat
>    multi combine (Str $x, Str $y) {$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. 


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About