On Mon, Oct 26, 2009 at 6:19 PM, Darrin Thompson
<darrinth@gmail.com> wrote:
On Sun, Oct 25, 2009 at 4:51 PM, Michael Snoyman <
michael@snoyman.com> 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.
>
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