On Thu, Jun 26, 2008 at 04:50:21PM +0200, Moritz Lenz wrote:
: I assume that 'Num' is meant to be a non-complex.
: Then it seems to make sense to assume:
: Int is Rat
: Rat is Num
: Num is Complex
: or am I off again?
Well, there's this little thing called Liskov substitutability...
Neither "is" nor "does" is quite right here, because the mathematicians
have seen fit to confuse representation semantics with value semantics. :)
I think what we want is something more like
Int as Rat
Rat as Num
Num as Complex
where "as" means, A is not a B because it limits the methods that
can be applied, and A doesn't do B because it doesn't have the right
native representation internally, but A can be used as a B by explicit
conversion to a value that either is or does B.
This declaration implies the existence of Rat(Int), Num(Rat), and
Complex(Num) functions and/or methods, as well as the authorization
for any such inferior A type to advertise itself as doing B, where
the VM somehow sneaks in the appropriate conversion for us if we
actually try to pass an Int to a Rat.
An interesting question arises as to whether "as" should be considered
transitive, or do we have to say
Int as Rat as Num as Complex
Rat as Num as Complex
Num as Complex
to avoid long chains of accidental conversions. One can argue both
sides of that: on the one hand, you don't want for type A to have
to worry about things regarding type C that are type B's bailiwick.
On the other hand, transparency of code suffers under transitive
coercion, and the syntax above is no great hardship. Plus we could
always add something spectacularly explicit like
Int as (Rat.as)
if people decide they give one. ;)
Larry
