Here's a very indirect answer, more a hunch: I'm not sure how, but what you're trying to do reminds me of Control.Applicative. Go take a look at the documentation and/or source code for that library, then follow the link to Applicative Programming with Effects Conor McBride and Ross Paterson http://www.soi.city.ac.uk/~ross/papers/Applicative.html which is one of the most beautiful papers ever written on Haskell. Even if I'm sending you on a wild goose chase, you'll enjoy the paper. I've had similar monumental struggles trying to push the type system past my understanding of how it works. I find that invariably, if I roll back one click on my ambitions, type "darcs revert", step outside for 30 seconds, then what I want to do works without incident on the next try. A good example of this is the "wrapper" class Sum in Data.Monoid. You'd think that one could just tell the type system that a Num is a Monoid, but the type system _really_ likes something to chew on, hence the wrapper. I spent way too long contemplating GHC error messages proposing the option -XLetGravityFailButDontBlameUs, before accepting that if there was a better way, it would be in the library code. So the key to maintaining momentum as a Haskell beginner is to see the simplification, one-click compromise that makes your obstacle trivial. Here, if I were you I'd first write your code for practice with the left- (or right-?) most === a different operator. By analogy with Applicative, or with the . . . . $ pattern one sees everywhere when composing. Then maybe it will be clear how to write it the way you want. On Jan 5, 2009, at 6:40 PM, dcmorse+haskell@gmail.com wrote:
Learning from the example of "read" and also Real World Haskell, I come across the idea to overload my function's return types. Trying to think of an application for this, I've always wanted to write == applications like in Icon, that is
a === b === c means a == b && b == c.