Is there some way of preventing the type mechanism from generating code for the instance type, as opposed to the class?
I don't understand this question - does the explanation above help?
I could have been clearer with my questions. What I was wondering was: is there some situation where the compiler can't statically determine the type to be used?
The function "double" will work on any type in the class Num, so the compiler can't know which "+" function to use.
When it's applied, the compiler will know the types of the arguments, won't it?. Which means that you would generate a version of double for each (applied) instance of Num. I don't doubt that there's a good reason this is not done: code bloat? or are there simply some expressions that can't be statically resolved? I suppose I was thinking: is the language design sufficiently clever that it's *always* possible for the compiler to infer the type instance in use, or are there some situations where it's not possible to infer the instance, so some kind of function dispatch mechanism is necessary?
Yes, roughly. In Haskell, the compiler always figures out the types of everything at compile time. This means it can often figure out which bit of code to use at compile time as well - but because of polymorphism, not always. Consider this bit of code:
double :: Num a => a -> a double x = x + x
The function "double" will work on any type in the class Num, so the compiler can't know which "+" function to use. But it *doesn't* solve this by run-time dispatch, like in C++. Instead, it compiles double like this:
double' :: NumDict a -> a -> a double' d x = let f = plus d in x `f` x
where NumDict is a record a bit like this:
data NumDict a = NumDict { plus :: a -> a -> a, minus :: a -> a -> a, fromInteger :: Integer -> a ... }
NumDict is called a "dictionary", and any time double' is called, the caller must supply the right dictionary. If you write
double 2.0
then the compiler sees that you've written a Double, and so supplies the NumDict Double dictionary:
double' doubleNum 2.0
where doubleNum :: NumDict Double contains the methods for adding Doubles, subtracting them, and converting from Integers to them.
This looks like a dispatching mechanism to me. However, I think I see that this can still be done at compile-time. When double is applied to 2.0, the compiler generates the double' doubleNum 2.0 code, which is still statically resolvable. The advantage seems to be that you don't generate a double function for each Num instance. Does this also mean that a dictionary class is created for every class, and a dictionary created for every instance?
Getting back to your original question, there's a little subtlety in Haskell to do with literals. Whenever you type an integer literal like "2", what the compiler actually sees is "fromInteger 2". Another little subtlety called "defaulting" (see the Haskell 98 Report, in section 4.3.4) arranges that in this
I knew about the "fromInteger" and similar treatment of literals, but the defaulting system is news to me. I've skimmed over the Haskell report, but details like this never sink in until you encounter them in practice...
Instance exporting is not easy to control in Haskell; if you export a type, then all its instances are exported along with it automatically.
Thanks. I wasn't sure how the export mechanism worked with regard to classes and instances; I just took a (wrong) guess that you could control export of classes and types separately. ***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************