Mark J. Reed wrote: > On Thu, Jun 26, 2008 at 10:23 AM, Moritz Lenz > <[EMAIL PROTECTED]> wrote: >> Thanks for the effort, but it also raises new questions. For example: >>> Int is Num >> Rakudo doesn't do it that way, because the 'A is B' relation in OO means >> "Every instance of A is also an Instance of B", which certainly isn't >> the case with Ints. Int is more like a subset of Num. > > Huh? If Int is a subset of Num, then every instance of Int *is* also > an instance of Num. That's what subset means...
Uhm, yes. I was confused, sorry. > Maybe you mean they are disjoint types in the type system, but the set > of numerical values of all possible Ints is a subset of the set of > numerical values of all possible Nums? But then how is type > compatibility obtained? > >> Which made me think, shouldn't Num be a role? and then 3.14 would be a >> Rat or a Float or whatever, 42 would be an Int, and >> Int does Num >> Rat does Num > > But Int should do Rat, too... > >> That way a compiler that only implements classes and roles (and no >> subset types) can get the hierarchy of numeric types right. > > ...assuming it's a hierarchy in the first place. What's the alternative? I don't think it's a good idea to special-case numeric types, and I don't think it's a good idea to define multis for each numeric type either. 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? Anyway, for our work in the test suite it would be nice to have it specced somewhere. Or should I rely on Ryan's docs/p6types? If so, it would be nice to convert it to format that can smartlinked to. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
