Re: Messing with the type heirarchy
On 7/27/05, Larry Wall [EMAIL PROTECTED] wrote: On Wed, Jul 27, 2005 at 11:00:20AM +, 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
Re: Messing with the type heirarchy
Luke Palmer wrote: 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.
Re: Messing with the type heirarchy
On Wed, 27 Jul 2005, [ISO-8859-1] TSa (Thomas Sandla?) wrote: 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. z3 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...
Re: Messing with the type heirarchy
HaloO Michele,
you wrote:
On Wed, 27 Jul 2005, [ISO-8859-1] TSa wrote:
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. z3 to
mean z is real AND as a real number is less than 3.
Which in Perl6 is written as
Complex where { .imaginary =:= 0|Undef } does Num;
somewhere in the Complex package. This would make your
intensions possible by dispatching to infix:{''}:(Num,Num)
but still preventing the general case.
--
$TSa.greeting := HaloO; # mind the echo!
Messing with the type heirarchy
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.
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
Re: Messing with the type heirarchy
[sorry Luke, I hit Send too soon] On 7/27/05, Luke Palmer [EMAIL PROTECTED] 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
Re: Messing with the type heirarchy
Hi,
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!|
Re: Messing with the type heirarchy
On 7/27/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
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).
Re: Messing with the type heirarchy
HaloO,
Ingo Blechschmidt wrote:
I've probably misunderstood you, but...:
role Complex does Object {...}
Num does Complex;
# That should work and DWYM, right?
My 0.02: Complex should provide e.g. a + that, when
called with two Nums, doesn't bother the return
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
shouldn't treat undef == false but as any(true|false).
Otherwise funny things can happen (as was observered
correctly in another thread about != applied to any
Juntions). In code:
if $c 3 { die if $c.does(Complex) }
This is the Perl6 representation of the following
sentence: If Any::$c is less then Int::3 then
die if this $c does behave like a Complex. I hope
$Larry likes it. BTW, is their a plain english output
module planned, that would produce the above automatically?
Don't question (Light ::= Particle|Wave) with a double
slit! At least not if you want a deterministic answer
where it actually passed.
tie rant
Imagine a Casino that hands out ties to players
who don't have one even though the Casino is
a tied area. If a Num playing in the Casino likes
the imaginary standard tie it can keep it. But
among Nums this imaginary tie is no differentiator.
Actually other Num methods will say: A tie? I see
no tie. Must be an imaginary one. In simple
environments the tie might not even be applicable
imaginarily. Thus it's stripped off or entrance is
denied. Under all cicumstances the Num may decide
how to deal with this tieing.
fun: d(en)ie(d) == die in the end :)
/tie rant
The only question is how much effort all this is for
(1) the implementor of Complex
(2) the implementor of Num
(3) the user of either one in isolation
(4) when they come together
In particular the user in (4) should be able to
state his expectations in a form that is checkable
by the VM. Which basically means that (1) and (2)
have to state their assumptions to the VM in the
same form/syntax.
--
$TSa.greeting := HaloO; # mind the echo!
Re: Messing with the type heirarchy
On Wed, Jul 27, 2005 at 11:00:20AM +, Luke Palmer wrote:
: 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
