'Convertible' class?

[Marcin 'Qrczak' Kowalczyk]

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