i haven't thought this through, but a variant of your first option may be to factor out extendedGCD into a class PIDEXT that is a parent of PID (occurs in the context of the declaration of PID). this way both methods will be available in PID.
advantages: the dependencies are a little more explicit
cycles are easier to avoid.
drawbacks: more complicated interface
less flexibility in implementation
also i think there was an issue with superclass constraints not being
inferrable from explicit subclass constraints, leading to bulky type
signatures all over the code that is using your classes.
but perhaps this gives somebody a better idea?
m.
On Mon, Nov 06, 2006 at 06:34:07PM +0100, Henning Thielemann wrote:
> To: Haskell Cafe <haskell-cafe@haskell.org>
> From: Henning Thielemann <[EMAIL PROTECTED]>
> Date: Mon, 06 Nov 2006 18:34:07 +0100 (CET)
> Subject: [Haskell-cafe] How to design default implementations of type class
> methods?
>
>
> I like to hear some opinions about how to implement class method defaults.
>
> Let's consider the following example:
> I want to classify types which allow for computation of the greatest
> common divisor. The greatest common divisor can be computed by Euclid's
> algorithm in some cases (integers, univariate polynomials) but not in all
> cases (integer matrices, multivariate polynomials). So maybe it's a good
> idea to set the Euclidean algorithm as default implementation for the GCD
> method. Say, I have already implemented both the normal Euclidean
> algorithm as "euclid", which only emits the GCD, and the extended
> Euclidean algorithm "extendedEuclid" which also determines a and b in
> "gcd(x,y) = a*x + b*y" for given x and y.
>
> Now I have two choices for implementing default methods:
>
> 1. Implement a method by calling other methods of the same class.
>
> class (Units a) => PID a where
> extendedGCD :: a -> a -> (a,a,a)
> extendedGCD = extendedEuclid divMod
>
> gcd :: a -> a -> a
> gcd x y = let (g,_,_) = extendedGCD x y in g
>
> Advantage: User must implement only few methods,
> here extendedGCD, the other ones work automatically.
> Disadvantage: User must know, how the default methods call each other,
> in order to not introduce cycles.
>
> 2. Implement a method by calling custom code,
> preferably a public function according to
> http://www.haskell.org/haskellwiki/Slim_instance_declaration
>
> class (Units a) => PID a where
> extendedGCD :: a -> a -> (a,a,a)
> extendedGCD = extendedEuclid divMod
>
> gcd :: a -> a -> a
> gcd = euclid mod
>
> Advantages/Disadvantages are negated with respect to the first item. :-)
>
>
> Ok, this example class is not well chosen, because in the case of
> multivariate polynomials, not only extended Euclidean algorithm fails, but
> it is in many cases not possible to represent the GCD of x and y as a
> linear combination of x and y.
>
> My question is not limited to this case: I want to know, what reasons
> exist pro and cons each alternative. Currently I prefer the first way,
> because it reduces the work of implementing instances to the things that
> are essential for the particular type. People who want specialized and
> more efficient methods, must implement all methods.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Institute of Information Systems, Humboldt-Universitaet zu Berlin
web: http://www.wiwi.hu-berlin.de/~fis/
e-mail: [EMAIL PROTECTED]
tel: +49 30 2093-5742
fax: +49 30 2093-5741
office: Spandauer Strasse 1, R.324, 10178 Berlin, Germany
pgp: AD67 CF64 7BB4 3B9A 6F25 0996 4D73 F1FD 8D32 9BAA
signature.asc
Description: Digital signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
