In thinking about various issues with the numeric classes, I came up with the following question: Is there a problem with having a class 'Convertible' as follows? class Convertible a b where convert :: a -> b So, e.g., fromInteger and fromRational could be replaced with convert. (But if you did the same thing with toInteger and toRational as well, you run into problems of overlapping instances. I think there are good semantic reasons for this: fromInteger and fromRational can be defined in terms of the basic +,*,zero,one, while toInteger and toRational rely on details of the representation.) What do people think of this idea in general? Perhaps a better name would be 'Subtype'? Note that "convert . convert" would be up there with "show . read" as an ambiguous term. Best, Dylan Thurston
Hello! On Wed, Feb 07, 2001 at 03:43:59PM -0500, Dylan Thurston wrote:
In thinking about various issues with the numeric classes, I came up with the following question: Is there a problem with having a class 'Convertible' as follows?
class Convertible a b where convert :: a -> b
[...]
Why not better: class Subtype a b where {- a is subtype of b, if following operations exist -} inject :: a -> b project :: b -> Maybe a Kind regards, Hannah.
On Wed, Feb 07, 2001 at 10:19:33PM +0100, Hannah Schroeter wrote:
Hello!
On Wed, Feb 07, 2001 at 03:43:59PM -0500, Dylan Thurston wrote:
In thinking about various issues with the numeric classes, I came up with the following question: Is there a problem with having a class 'Convertible' as follows?
class Convertible a b where convert :: a -> b
[...]
Why not better:
class Subtype a b where {- a is subtype of b, if following operations exist -} inject :: a -> b project :: b -> Maybe a
Shouldn't this be a subclass? 'project' is not always easy or possible to define. Best, Dylan
Hello! On Wed, Feb 07, 2001 at 05:43:40PM -0500, Dylan Thurston wrote:
[...]
class Subtype a b where {- a is subtype of b, if following operations exist -} inject :: a -> b project :: b -> Maybe a
Shouldn't this be a subclass? 'project' is not always easy or possible to define.
Good question. The term subclass is, however, not according to Haskell's type system. Therefore: class Subtype a b where inject :: a -> b class Subtype a b => ProjectableSubtype a b where project :: b -> Maybe a (or can someone imaging a constellation where project makes sense but inject does not? In that case, the two classes should be completely independent instead) Kind regards, Hannah.
Wed, 7 Feb 2001 15:43:59 -0500, Dylan Thurston <dpt@math.harvard.edu> pisze:
class Convertible a b where convert :: a -> b
So, e.g., fromInteger and fromRational could be replaced with convert. (But if you did the same thing with toInteger and toRational as well, you run into problems of overlapping instances.
There is no difference between fromInteger/fromRational and toInteger/toRational in this respect. Either of them could be replaced with convert, but not both. And convert cannot be a substitute for fromIntegral/realToFrac, because it needs a definition for every pair of types. I'm not sure if it buys much, and there are disadvantages. The type more easily leads to ambiguities. fromInteger at least forces the source type to be Integer. Using convert when an argument is not determined in other places is ambiguous. You can put Num a in some instance's context, but you can't put Convertible Integer a. It's because instance contexts must constrain only type variables, which ensures that context reduction terminates (but is sometimes overly restrictive). There is ghc's flag -fallow-undecidable-instances which relaxes this restriction, at the cost of undecidability.
What do people think of this idea in general? Perhaps a better name would be 'Subtype'?
It would suggest that it's reflexive and transitive, where in fact it's not. It can be argued that seeing convert for all types of conversions decreases readability instead of increasing it. It does not give a hint what kind of conversion it is: changing the representation of a collection, turning a sequence into a set, turning a sequence of bits into an Integer, or whatever. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
participants (3)
-
Dylan Thurston -
Hannah Schroeter -
qrczak＠knm.org.pl