Re: Maybe a, The Rationale

On 2008 May 11, at 22:42, Don Stewart wrote:

> ok:
>>> Maybe types force you to deal with it, while simultaneously
>>> providing convenience functions to help you deal with it.
>>
>> I readily grant that Maybe is a wonderful wonderful thing and I use  
>> it
>> freely and
>> voluntarily.  BUT it should not dominate the code.
>>
>> Consider Haskell's getChar and hGetChar.  They DON'T return Maybe
>> Char; they
>> raise an exception at end of file.  You have to keep testing isEOF/
>> hIsEOF before
>> each character read, as if we had learned nothing since Pascal.
>> Arguably, maybeGetChar :: IO (Maybe Char) and hMaybeGetChar ::  
>> Handle -
>>> IO (Maybe Char)
>> would be a good idea, at least then one could easily set up some
>> combinators to
>> deal with this nuisance.
>
> Thankfully its easy to lift IO-throwing things into a safer world.
>
>    import Control.Exception
>    import Prelude hiding (getChar)
>    import qualified Prelude as P
>
>    getChar :: IO (Maybe Char)
>    getChar = handle (const (return Nothing)) (Just `fmap` P.getChar)

And it's a monad, so it doesn't have to dominate the code; you can  
write your code monadically and let the scaffolding deal.

--

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH