Re: MML dispatch

Front page | perl.perl6.language | Postings from July 2005

Thread Previous | Thread Next

From:

David Storrs

Date:

July 13, 2005 13:12

Subject:

Re: MML dispatch

Message ID:

B1AC374A-2C50-4F4C-AD77-790AE59820E1@dstorrs.com

On Jul 13, 2005, at 1:12 PM, Larry Wall wrote:
>
> If class Dog does role Bark and also does role Wag, then passing a
> Dog to
>
>     multi (Bark $x)
>     multi (Wag $x)
>
> should result in ambiguity.

My understanding is that a Role is an abstract (i.e. cannot be  
instantiated) blob of methods and, possibly, data.  The purpose of a  
Role is to paste it into a class--in other words, a Role is a not a  
type, it is a part of a type.  Assuming that that understanding is  
correct, then I would expect the above multi declarations to be a  
compile time error:  'multi (Wag $x)' means "expect some data, call  
it $x, which will be of type Wag"...but Wag isn't a type, it's a  
partial type.

I would require that declaration to be written as one of the following:

     multi (Dog does Bark $x)        # Dog is an actual type that can  
be instantiated
     multi (Animal does Bark $x)    # Animal is an abstract base class
     multi (Object does Bark $x)    # Object (or whatever the name  
is) is the root of the entire class/type hierarchy

I could see stretching a point and allowing the last one to be  
rewritten as:

     multi (does Wag $x)    # Still references root type, but implicitly

The point of this is to force the programmer to give a reasonable  
constraint...when they expect something that Wags, does it need to be  
a Dog, or will any Animal that can Wag be sufficient?  Or are they  
really looking for absolutely anything that is capable of Wagging?

Doing it this way would (I think) be both more intuitive and would  
resolve a lot of the ambiguity that was discussed farther on.

     multi (does Bark $x)
     multi (Dog does Bark $x)    # Dog is more specific than "any  
data type"

---new example

     multi (Tree does Bark $x)
     multi (Dog does Bark $x)    # Equally specialized classes in  
separate parts of the hierarchy.  If passed an "Object does Bark"  
param, this should be an error.

---new example

     multi (Labrador does Bark $x)    # Labrador is a subclass of Dog  
and therefore more specific if passed a Labrador param
     multi (Dog does Bark $x)         # This catches any other 'Dog'  
params
     multi (does Bark $x)             # This catches anything else  
that Barks, including 'Dingo is Dog does not Bark'

> The interesting question is whether N should
> be 0 or 1 (or possibly epsilon).  If we have
>
>     multi (Bark $x)
>     multi (Dog $x)
>
> arguably Dog is more specialized than Bark,
> [...]
> The problem with N == epsilon is in visualizing how Dog is more  
> constrained
> than Bark.

Assuming that the declaration of Dog is 'class Dog does Bark', then  
yes, I think Dog should be considered more specialized than Bark-- 
lots of things might Bark, but only a Dog will bark in precisely this  
way.  Or, to put it a different way, a 'Dog' class has a certain  
specificity and a 'Bark' Role has a certain specificity: the  
combination of the two produces something more specific than either.   
(And, of course, 'Dog does Bark does Wag' (or 'Dog does Bark&Wag' if  
you prefer) is yet more specific.)

--Dks

Thread Previous | Thread Next