[Haskell] modern language design, stone age tools
S. Alexander Jacobson
alex at alexjacobson.com
Wed Jun 23 16:24:06 EDT 2004
Thank you for the programming practice
recomendation, but I would still prefer to
have something like the implicit parameters
solution I described.
The solution you describe forces you to put code
in functions to handle cases that are outside its
domain. Usually I just want to know what function
are calling with the pathological input.
e.g.
quadratic a b c = read $ show ((-b + root)/2/a),(-b - root)/2/a)
where root = sqrt(b*b - 4*a*c)
I want to know which function is passing in things
to make the root imaginary or a==0. I don't want
to rewrite this function so it handles these
exceptions explicitly.
-Alex-
_________________________________________________________________
S. Alexander Jacobson mailto:me at alexjacobson.com
tel:917-770-6565 http://alexjacobson.com
On Wed, 23 Jun 2004, MR K P SCHUPKE wrote:
> I like to write programs so functions cannot fail...
> so head should really be:
>
> maybeHead :: [a] -> Maybe a
> maybeHead (a:_) = Just a
> maybeHead _ = Nothing
>
> etc...
>
> The the calling function can do something like:
>
> case maybeHead x of
> Just y -> <expr y>
> Nothing -> fail "failed in..."
>
> This way you can pass the failure back up to somewhere where
> its meaningful.
>
> In my opinion you should either be encoding failure in the
> return type, or using exceptions... anything else is just
> bad coding.
>
> Finally use guards (that can be conditionally compiled out)
> before functions that might fail:
>
> if null x then fail "sesible error message" else ...
>
> Keean.
>
More information about the Haskell
mailing list