You may be interested in a trick relating to type classes which can address this issue, though it's not the "Haskell way to do it." You can define Show as a data type, rather than a type class: type Show a = Either (a -> String) (Int -> a -> String -> String) show :: Show a -> a -> String show (Left s) x = s x show (Right sp) x = sp 0 x "" showsPrec :: Show a -> Int -> a -> String -> String showsPrec (Left s) n a str = s a ++ str showsPrec (Right sp) n a str = sp n a str A function using this "class" would take it as its first argument: print :: Show a -> a -> IO () The constructors for Show make explicit the two ways to define an instance. This technique also has the advantage of allowing multiple, non-conflicting instance declarations, selectable at runtime. Using Show as an example, you might have instances representing both formatted and unformatted display. An obvious disadvantage is that the instance needs a name and gets passed explicitly. Mike On Thu, Dec 27, 2007 at 04:34:06PM +0000, Hugo Macedo wrote:
Dear all
A student from a beginners course on Functional Programming came to me with a problem, he declared a type like:
data WeekDay = Mon | Tue | Fri -- ...
He had forgot to complete a Show instance definition.
instance Show WeekDay where (empty)
Then he complained about getting *** Exception: stack overflow when he tried to invoke some function on that type.
After checking the Haskell98 grammar I found out that this is allowed syntactically and probably semantically too. Is there any reason to do that?
Now I'm wondering: Shouldn't a class be an warranty of a well defined interface? Thus forcing the user to define the show function or showPrec? Am I missing any point?
My best regards, Hugo
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell