[Haskell-cafe] Maybe a, The Rationale
Brandon S. Allbery KF8NH
allbery at ece.cmu.edu
Sun May 11 23:10:05 EDT 2008
On 2008 May 11, at 22:42, Don Stewart wrote:
>>> 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
>> 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
More information about the Haskell-Cafe