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

RE: multi scoping

Thread Previous | Thread Next
From:
Thomas Sandlass
Date:
September 5, 2005 02:53
Subject:
RE: multi scoping
Message ID:
8B2D97A317E8C9479E35FED99ADC3096CCC8C1@br2mex01.orthogon.com
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





Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About