Andre Pang wrote:
The syntactic sugar is the killer. (Using monads is really no fun if you don't have do notation, for example. Doable: yes. Pretty: definitely not!) Even if you use Template Haskell to try to implement the syntactic sugar, you're very limited by the splice $(...) notation at the call site. I've always argued that Haskell really should have a full-blown macro system: it would really help with Haskell and EDSLs, and of course for integrating these kinds of libraries. TH is 90% of the way there, and with a bit more thought, those pesky splices could just magically disappear ... ;)
Its not that bad... the trick I am using is lifting existing haskell syntax, so an interface definition looks like: $(interface [d| data MyInterface = MyInterface { method1 :: ..., method2 :: ..., method3 :: ...} |]) So we define a normal haskell98 record, and the TH lifts it to an interface definition using extensible records. An implementation looks would possibly look like: $(implementation [MyInterface] [d| method1 = ... method2 = ... method3 = ... |])
Yes, also agreed. I did some similar Haskell<->OO integration work, and the type errors which appeared when something went wrong are quite awesome. User-defined compile-time errors would be fantastic, but that would require quite a lot of effort.
We can do something better than what we have at the moment, for a start TH can generate user defined compile time errors - but we don't want to have to implement our own typechecking, so we can supplement this with a class with no instance and empty types: class Fail a data Some_user_defined_error instance Fail Some_user_defined_error => Test ... So the compiler will report an undefined instance in Fail for your error type, but you can at least get some readable text, which is better than nothing. Keean.