[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