Larry Wall wrote:
> 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.
Or in other words, our type system can't really express the relation.
I know that Eiffel found an interesting workaround through their "Design
by Contract" system. It works like this, ported to Perl 6:
class Complex {
method can_do_sqrt {
True;
}
method sqrt {
PRE { self.can_do_sqrt() }
# calculation here
}
}
class Num {
method can_do_sqrt {
self >= 0;
}
}
Through the polymorphic preconditions one can escape the Lady Liscov.
Can we use something similar, perhaps? (I have no idea how and if that
can be transferred to types, I'm just think aloud here)
> 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.
That's fine by me, as long as user defined mathematical types have the
same ability to provide these automatic conversions, and the type
checker and MMD dispatcher honours these conversion.
> 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. ;)
Usually when there are two equally valid sides, we try to give the
programmer the opportunity to pick one. Atm I don't see how we can do
that here, but perhaps somebody has a good idea how we can get around
making that decision?
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
