From: Joshua Juran <[EMAIL PROTECTED]>
   Date: Sat, 25 Jun 2005 01:05:35 -0400

   On Jun 24, 2005, at 11:02 PM, Bob Rogers wrote:

   > Since Complex could also be considered a Number, but of a very 
   > different
   > sort, it might be worth constructing the type hierarchy to reflect 
   > this:
   >
   >    Scalar
   >       Number
   >          Real
   >             Integer
   >             Float
   >          Complex

   This is inaccurate.  All integers are reals (in fact, all integers are 
   rationals and all rationals are reals), but floats are not all 
   integers.  Factorial should be defined for integers but not floats.

That's pretty much what I thought I had said.  But I notice that the
indentation on Float used a tab, but not on Integer, so I'll bet your
mail client displayed them differently.  (I've converted them all to
spaces above.)

   Also, all reals are complex numbers (with a zero imaginary component).  

That is mathematically accurate, but inconvenient to implement [1].

   Here's my suggested hierarchy with abstract types in lowercase and 
   instantiable types capitalized:

        scalar
                number (possibly complex)
                        real
                                rational
                                        integer
                                                Integer
                                                BigInt
                                        Ratio
                                Float
                        Complex
                        Quaternion
                String
                ...

Except for Quaternion, this is very close to the Common Lisp type
hierarchy for "number" [1], which was the inspiration for my proposal.
I had left out rational and Ratio because I don't think any of the
Parrot core languages require them, but it would make life easier down
the road if "rational" were included in the core type hierarchy.

   FWIW, the main difference is that CL also subdivides Complex into
(complex float) and (complex rational), but that is best left to a
Lisp-specific subclass in any case.

   Also, what about non-scalar numbers such as vectors and matrices?  Will 
   we have operators for dot-product and cross-product?  Or is this 
   another HLL issue?

   Josh

I think it's an HLL thing; it seems like a big piece to implement in
Parrot.  Such an implementation might be useful to support perl6
hyperoperators, but IMHO this is better left to generated PIR.

                                        -- Bob

[1]  http://www.lispworks.com/documentation/HyperSpec/Body/t_number.htm,
     "Notes" at the bottom of the page.

Reply via email to