George Russell wrote:
I like the idea too, not just for Show but for any instances. It seems to
me that in general you should be able to combine the convenience of the
Haskell type system with the power of Standard ML's structures and functors.
It looks like it would be easy, but it's very hard.
The reason type classes work so well right now is that they have a straightforward interpretation as restrictions on the universe of quantification of a type variable. When we translate Haskell to System F, dictionaries come along for the ride as run-time representatives of types.
If more than one dictionary is allowed per type, this correspondence breaks down, and all hell breaks loose as a result. We've already seen this happen with implicit parameters. In a program with implicit parameters:
* Beta conversion no longer preserves semantics.
* The monomorphism restriction is no longer a restriction: it sometimes silently changes the meaning of a program.
* Adding type signatures for documentation is no longer safe, since they may silently change the behavior of the program.
* It's not even safe in general to add a signature giving the same type that the compiler would infer anyway: there are (common) cases in which this too changes the program's meaning. I ran into this quite by accident the first time I tried to use implicit parameters, and it was enough to scare me away from ever trusting them again.
Your proposal, simple though it seems, would extend all of these problems to type classes.
Since it hasn't been mentioned yet I should also point people once again to "Functional Pearl: Implicit Configurations" by Oleg and Chung-chieh
Shan, which ingeniously uses polymorphic recursion to construct type class instances at run time. If there's a safe and sane way to add local dictionaries to the language, it's probably along those lines.
-- Ben
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
