
On Mon, Oct 26, 2009 at 6:19 PM, Darrin Thompson
On Sun, Oct 25, 2009 at 4:51 PM, Michael Snoyman
wrote: Comments are most welcome. I would like this to be a suitable replacement for the ubiquitous Maybe, (Either String) and ad-hoc Result data types so often used to report a failure. I'd be very happy to improve the package for the general community.
I haven't actually tried writing code with this, just read the api docs. The api makes a lot of sense to me.
I'm a Python/Ruby guy. I see Haskell as short like Python, almost fast like C. Your attempt monad thing _makes_ _sense_ to me.
One little nit I guess. Python had "string as exception" for awhile, now they discourage that. There seems to be a historical pattern where the right way to throw exceptions changes from throwing strings to throwing real exception objects. Would it be possible to skip the string one here? Are extensible exceptions too cumbersome for some cases?
I'm not sure what you mean. The main method used here *is* real exceptions. If you're referring to the failureString method, I think it's valid for simple use cases. The fact is, it's a little cumbersome (to use your terminology) to actually declare an instance of Exception. For example, if I want an exception for too many hotdogs (?!) I'd have to write: {-# LANGUAGE DeriveDataTypeable #-} -- needs to be at the top of the file import Data.Generics -- needs to be in the import list import Control.Exception -- same data TooManyHotDogs = TooManyHotDogs Int deriving (Show, Typeable) instance Exception TooManyHotDogs Maybe a good approach would be to make it easier to makes Exception types (template Haskell comes to mind). If anyone has any ideas on this front, I'd be happy to hear it. Michael