On Wed, Sep 23, 2009 at 7:59 PM, Brad Larsen
The trouble comes in when defining a more general arithmetic expression type class. Suppose we want polymorphic arithmetic expressions:
class PolyArithExpr exp where constant :: a -> exp a addP :: exp a -> exp a -> exp a
We then try to define an evaluator:
-- instance PolyArithExpr E where -- constant = E -- addP e1 e2 = E (eval e1 + eval e2) -- bzzt!
The instance definition for `addP' is not type correct: Could not deduce (Num a) from the context () arising from a use of `+' at /home/blarsen/mail.lhs:42:20-36
One way to remedy this is to change the class definition of PolyArithExpr so that `addP' has a Num constraint on `a':
class PolyArithExprFixed exp where pae_constant :: a -> exp a pae_add :: Num a => exp a -> exp a -> exp a
which allows us to define an evaluator:
instance PolyArithExprFixed E where pae_constant = E pae_add e1 e2 = E (eval e1 + eval e2)
I find this ``fix'' lacking, however: to define a new interpretation of the EDSL, we may be forced to change the DSL definition. This is non-modular, and seems like an instance of the expression problem. (There may be a multiparameter type class solution for this.)
I don't know what you expect from pae_add, such that it could "add" a couple of a's without knowing anything about them. Don't think of Num as a implementation detail, think of it as information about that a. An implementation which adds another typeclass constraint is requiring too much information, and either the implementation is undefinable (that happens, but it's always for a good reason), or the interface is weaker than you wrote. I don't know what kind of implementation would add another constraint on a. Are you referring maybe to a specialized interpreter for Integer math? Well, if this is truly a polymorphic type that needs a constructor class, there could be some non-Integer math in the middle somewhere, and your interpreter would be incorrect. I would like to see an example of this unmodularity, making use of the polymorphism, so I can understand what you're asking better. Luke