[TYPES] A show-stopping problem for modular type classes?

[Brian Hulley]

Brian Hulley wrote:
> Actually even if we go back to plain Haskell 98 and consider the
> original types for the functions in Data.Set we can see that none
> of the types would be sufficient to describe the parameter
> requirements in a modular setting:
> 
>     data Set a = Set [a] -- example implementation
> 
>     insert :: Ord a => a -> Set a -> Set a
> 
>     union  :: Ord a => Set a -> Set a -> Set a

Over the last few days I've been thinking a bit more about this example, and although I still stand by my observation that the above code would be unsafe (i.e. type-correct but bug-friendly) in a scoped-instance context, and that the safety of the above example in a global-instance context can lead to a new insight regarding the question: "what *are* typeclasses?", it now seems to me that it would be an error to regard this as a justification for abandoning attempts to provide facilities for automatic type-directed synthesis of ML-style modules, hence this post, to make sure my earlier doom-laden comments are sufficiently cancelled out, and especially to make sure that no future reader of the archive may be led astray! ;-)

For me now the central point is that the concept of "typeclass" needs to be clearly distinguished from "type-directed module synthesis" so that programmers can thoroughly understand what guarantees the type system will and will not give them when they use the latter feature in a scoped synthesis-rule context.

Thanks to everyone who took part in the discussion. It's given me a lot more clarity about the issues,

Best regards,
Brian.