I don't like the idea of having Eq as a superclass of IsString. It's a gratuitous constraint. There are perfectly good examples where you have something being IsString, but not Eq. In fact, I implemented IsString just such an application. Sure, you can't use IsString for pattern matching quite as easily, but that's intentional. If I got to decide I'd get rid of all the gratuitous superclasses, like Show and Eq for Num. They just limit how you can use a class. (My application is a DSEL where string literal build an abstract syntax tree. The only way I can use Num is to make fake instances for Eq and Show, because those functions cannot really be implemented.) -- Lennart On Jan 30, 2007, at 17:12 , David Roundy wrote:
On Tue, Jan 30, 2007 at 01:54:02PM +0000, Ian Lynagh wrote:
+-- | Class for string-like datastructures; used by the overloaded string +-- extension (-foverloaded-strings in GHC). +class IsString a where + fromString :: String -> a + +instance IsString [Char] where + fromString xs = xs
Wouldn't it make sense to have IsString require an Eq instance?
class Eq a => IsString a where
so that string literals could be used in pattern matching? The only reason I could see not to do this would be if you wanted to make something like (Ptr CChar) be an IsString, but that seems pretty crazy to me. I guess you could make (ForeignPtr CChar) be an IsString, and that wouldn't be particularly crazy, but it still seems ugly, and reasonably pointless.
I'd rather have the inferred type of
foo "bar" = True
be
foo :: IsString a => a -> Bool
than
foo :: (Eq a, IsString a) => a -> Bool
or even worse, to have pattern matching not work as expected with -foverloaded-strings. -- David Roundy http://www.darcs.net _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries