Messing with the type heirarchy
Luke Palmer
This was a passing proposal to allow supertype declarations in
Haskell. I'm referencing it here because it's something that I've had
in the back of my mind for a while for Perl 6. I'm glad somebody else
has thought of it.
Something that is worth looking into is Sather's type system. I
haven't read anything about it yet, but worry not, I will.
Anyway, on to the proposal.
I've often thought that it would be very powerful to put types
in-between other types in the hierarchy. This includes making
existing types do your roles (which Damian describes as "spooky action
at a distance"). Allow me to provide an example.
Let's say that Perl 6 does not provide a complex number class by
default. How would you go about writing one? Well, let's do the
standard Perl practice of making words that your users are supposed to
say in their code roles.
role Complex {
# implementation details are unimportant (as always :-p)
}
Now, where does it belong in the type heirarcy so it can interact well
with standard types? It belongs *above* Num (and below whatever is
above Num). Everything that is a Num is a Complex right? It just has
a zero imaginary part. But currently that is impossible. So we have
to define conversions, which behave quite differently from simple
interface compatibilites. For one, we have to reference a concrete
complex type. Basically, we've made Complex feel like an outsider to
the Perl standard hierarchy.
As another example, let's say I'm implementing my own Junction class,
MyJunction. I want it to be lower precedence than standard Junctions
(for an appropriate definition of precedence; in this case, it means
it will be threaded first). Put aside for the moment how we define
the multimethods for all existing subs at once.
The safe way to implement a threading object is to give it its own
level in the type hierarchy. For example, to do Junction, we
structure the type hierarchy like so:
Any
|- Junction
|- JunctionObject # or some other appropriate name
|- Object
|- ...
Then we can safely define MMD variants and be sure that they won't
change their semantics when derivation levels change under manhattan
distance. Under pure ordering, we prevent against ambiguity errors
(which is in fact how I came up with this pattern).
So, anyway, to define MyJunction, I'd like the hierarchy to look like this:
Any
|- MyJunction
|- MyJunctionObject
|- Junction
|- JunctionObject
|- Object
|- ...
This is a case where it is absolutely necessary to supertype in order
to achieve certain semantics.
Okay, now that I have the need out of the way, the syntax is obvious:
role Complex
does Object
contains Num
{...}
There is probably a better word than "contains". I was thinking set
theory when I came up with that one.
It might be wise only to allow this for roles if we go with a
derivation metric-based MMD scheme. Allowing this for classes would
mean that you could add depth to the metric that the author of the
classes in question didn't intend, and I've already shown that you can
screw up manhattan MMD semantics at a distance, spookily, if you do
that.
Luke
Ingo Blechschmidt
Luke Palmer wrote:
> http://repetae.net/john/recent/out/supertyping.html
>
> This was a passing proposal to allow supertype declarations in
> Haskell. I'm referencing it here because it's something that I've had
> in the back of my mind for a while for Perl 6. I'm glad somebody else
> has thought of it.
[...]
> role Complex
> does Object
> contains Num
> {...}
I've probably misunderstood you, but...:
role Complex does Object {...}
Num does Complex;
# That should work and DWYM, right?
--Ingo
--
Linux, the choice of a GNU | Wissen ist Wissen, wo man es findet.
generation on a dual AMD |
Athlon! |
Aankhen
On 7/27/05, Luke Palmer <lrpa...@gmail.com> wrote:
> > There is probably a better word than "contains". I was thinking set
> > theory when I came up with that one.
What about "derives"?
Aankhen
Luke Palmer
> Luke Palmer wrote:
> > role Complex
> > does Object
> > contains Num
> > {...}
>
> I've probably misunderstood you, but...:
>
> role Complex does Object {...}
> Num does Complex;
> # That should work and DWYM, right?
Supposing that you can actually do that, and that "Num does Complex"
gets executed at compile time. I didn't know you could add "does"
declarations to classes referring to other classes (rather than making
the class object do a metaclass role... though I admit that that would
only be warranted by a pretty bizarre situation).
Larry Wall
: Let's say that Perl 6 does not provide a complex number class by
: default. How would you go about writing one? Well, let's do the
: standard Perl practice of making words that your users are supposed to
: say in their code roles.
:
: role Complex {
: # implementation details are unimportant (as always :-p)
: }
:
: Now, where does it belong in the type heirarcy so it can interact well
: with standard types? It belongs *above* Num (and below whatever is
: above Num). Everything that is a Num is a Complex right?
Not according to Liskov. Num is behaving more like a constrained
subtype of Complex as soon as you admit that "isa" is about both
implementation and interface. By the interface definition it's
slightly truer to say that Complex is a Num because it extends Num's
interface. But this is one of the standard OO paradoxes, and we're
hoping roles are the way out of it. (Or to be less precise and more
accurate, we're hoping it's the way to sweep the problem under N
carpets where N is greater than 0 most of the time.)
Larry
Michele Dondi
> value to carry on a useless imaginary part. And
> Complex should consistently return undef when compared
> to other Nums or Complexes. And the Compare role
My 0.02+0.01i: in mathematics it is commonly used to write e.g. z<3 to
mean "z is real AND as a real number is less than 3".
Michele
--
> Might I suggest you take nice strong draught of hemlock before you
> post again? I think we'll all be much better off...
You are besmearing the memory of Sokrates.
- David Kastrup in comp.text.tex, "Re: Is Kastrup..."
Luke Palmer
> On Wed, Jul 27, 2005 at 11:00:20AM +0000, Luke Palmer wrote:
>> Everything that is a Num is a Complex right?
>
> Not according to Liskov. Num is behaving more like a constrained
> subtype of Complex as soon as you admit that "isa" is about both
> implementation and interface. By the interface definition it's
> slightly truer to say that Complex is a Num because it extends Num's
> interface. But this is one of the standard OO paradoxes, and we're
> hoping roles are the way out of it.
Well, everything that is a Num is a Complex in a value-typed world,
which Num and Complex are in. I don't like reference types much
(though I do admit they are necessary in a language like Perl), and
I'm not sure how this fits there anymore. Anyway, that's beside the
point, since a supertyping need is still there for referential types.
Luke
Dave Whipp
>>>Everything that is a Num is a Complex right?
>>
>>Not according to Liskov .... But this is one of the standard OO
>>paradoxes, and we're hoping roles are the way out of it.
>
> Well, everything that is a Num is a Complex in a value-typed world,
> which Num and Complex are in. I don't like reference types much
> (though I do admit they are necessary in a language like Perl), and
> I'm not sure how this fits there anymore. Anyway, that's beside the
> point, since a supertyping need is still there for referential types.
Doesn't the problem largely go away if we allow Num to be a more general
numeric type, and introduce, say, Real for the more constrained set of
numbers that Num currently represents. Of course, if it were truely the
most general, then it'd permit quaternions, etc., but I think that most
people would be happy for Num to be a simplest possible complete
arithmetic type.