On Fri, May 16, 2008 at 07:23:57PM +0100, Neil Mitchell wrote:
Hi
Hello!
It's not nearly as nice as a solution in the type checker, since it relies on every user of the library running an extra tool if they want a safe interface.
True. But its 0 lines of code, rather than type class hackery - you pay a lot less, you get very slightly less. You can always alias ghc to ghc && catch.
The problem is that you can't always do this if you're the library writer, since you can't control all your users' configurations, so there are still plenty of good reasons to try to design good APIs! [...]
I'm not recommending we scrap the type system and embrace Catch instead. I'm just suggesting that sometimes instead of hacking the type system in ways that makes peoples heads hurt, there may be an alternative* :-)
Indeed, I certainly appreciate the existence of Catch--and don't really care for the API I suggested. But I also would be very surprised if Manuel or Simon couldn't come up with a far prettier API that would be just as effective (if we were willing to use type families in this package, which I don't recommend). When I see an API like this one with a very simple relationship between input and output that is forced to be dynamically checked, I can't help but think that we can do better than this. David