...

Paul: Hi folks

data Maybe a = Nothing | Just a

What is the underlying rationale for the Maybe data type? is it the safe style of programming it encourages/ Something tells me this is going to start a lengthy discussion. :-)

Bob: Pure and simple -- it allows you to represent partial functions. Looking up a map will only sometimes find a value, so we either return Nothing, or Just that value.

Paul: Would yu like to demonstrate this in an example? Cheers, Paul

On 2008 May 10, at 18:56, PR Stanley wrote:

...

...

Paul: Hi folks

data Maybe a = Nothing | Just a

What is the underlying rationale for the Maybe data type? is it the safe style of programming it encourages/ Something tells me this is going to start a lengthy discussion. :-)

Bob: Pure and simple -- it allows you to represent partial functions. Looking up a map will only sometimes find a value, so we either return Nothing, or Just that value.

Paul: Would yu like to demonstrate this in an example?

Um, I was encountering and recognizing times when I really needed an out-of-band "null", and the pain of representing such in C, shortly after I started serious programming in C (call it 1984-5). Is this really difficult? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Sat, May 10, 2008 at 3:10 PM, PR Stanley wrote:

...

...

...

...

Paul: Hi folks

data Maybe a = Nothing | Just a

What is the underlying rationale for the Maybe data type? is it the safe style of programming it encourages/ Something tells me this is going to start a lengthy discussion. :-)

Bob: Pure and simple -- it allows you to represent partial functions. Looking up a map will only sometimes find a value, so we either return Nothing, or Just that value.

Paul: Would yu like to demonstrate this in an example?

Um, I was encountering and recognizing times when I really needed an out-of-band "null", and the pain of representing such in C, shortly after I started serious programming in C (call it 1984-5). Is this really difficult?

Paul: Hmm, I'm not quite sure what you're driving at.

Me neither.

Cheers, Paul _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

...

...

...

Um, I was encountering and recognizing times when I really needed an out-of-band "null", and the pain of representing such in C, shortly after I started serious programming in C (call it 1984-5). Is this really difficult?

Paul: Hmm, I'm not quite sure what you're driving at. Me neither.

Null pointers, EOF markers, didn't find specified key in some tree, etc.

Paul: So much time is wasted on making the thing work even if you have perfectly sound semantics. Still, that's a hundred times more preferable to c++ and its anomalies and contradictions. What was Stroustroup thinking of! :- Cheers, Paul

On 12 May 2008, at 1:52 am, Brandon S. Allbery KF8NH wrote:

My real point was that in the C programming culture it was/is far too common to use an in-band value; that is, one that could be confused with or treated as a valid response: null pointers, stdio's EOF (= -1).

Here I must disagree. I've hacked character-level I/O in lots of programming languages (the last time I counted I'd used more than 100), and C was the first language I ever met that made it easy, precisely BECAUSE the perfectly normal "there are no more characters" situation was handled the same way as every other outcome.

This just causes problems because code is almost encouraged to ignore the special cases. For example, the ctype macros have to support being passed EOF.

So they do, but it is elementary to do so. The only reason there is anything even remotely unusual there is that the *same* functions are used in C for *character* input and *byte* input. I'll grant you that you probably don't want to process binary input using quite the same quasi-FSA code that you want for characters. Since C uses NUL for terminating strings, and since ASCII made it clear that NUL was never ever *supposed* to appear in text, NUL would have been the perfect choice for character EOF, and in that case there would never have been anything odd about having the ctype macros handle it. I've been writing some Smalltalk recently, which uses a Pascal-like convention aStream atEnd "test for EOF" ifTrue: [self handleEOF] ifFalse: [self handleCharacter: aStream next] and the EOF tests clutter up the code inordinately and make it so painful that C starts looking good again. The C approach here has several benefits: - you can *postpone* checking for EOF until after you have checked for other things; since EOF is seldom or never what the code is mainly *about* this is good for clarity - if you want to know "is the next character one of these" you have only two cases to deal with at that point (yes and no), not three (yes, no, and you-idiot-you-forgot-to-test-for-EOF-first-and-testing-for-EOF- is- the-most-important-thing-anybody-could-be-interested-in-when- reading).

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.

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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- "I don't want to discuss evidence." -- Richard Dawkins, in an interview with Rupert Sheldrake. (Fortean times 232, p55.)

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@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

IME "nullable by default" is one of the biggest sources of runtime crashes in high level OOP languages like C#, which is a shame because it really isn't that difficult to statically eliminate the vast majority of them, especially when you're sort of hand-waving the semantics of your language anyway and don't require it to be super rigorous...

I definitely agree. After I'd been learning Haskell for 6 months and then wrote a program in Java & C++, almost the first thing I did was code up a generic Maybe<T> class in each language. It is so much clearer and more obvious to _explicitly_ have no value (Maybe.Nothing()) as opposed to _implicitly_ having no value (null). Now I find my Java & C++ Maybe<T> class indispensable when I am programming in those languages. Eric

PR Stanley wrote:

...

Paul: What is the underlying rationale for the Maybe data type?

It is the equivalent of a database field that can be NULL.

Paul: shock, horror! the null value or the absence of any value denoted by null is not really in harmony with the relational model.

Ketil should have said: It is the equivalent of the extremely common way of misusing NULL. It doesn't bring in all the unpleasant baggage of three valued logic, but simple indicates an exceptional value. This use of NULL, very common in practical databases, frowned on by DB designers who understand about relational theory and normalisation, is prevalent precisely because common SQL dialects really make it a pain to invent your own datatypes, so it's hard to "add an exceptional value". Practical programming needs a particular exceptional value very often indeed, to model things like optional parameters. If common SQL dialects supported types like 'Maybe Int' natively, then NULL could be used much less. Jules PS Students of NULL and 3-valued logic will note that some of the problem therein can be studied in Haskell by comparing (==) and liftM2 (==) as functions on Maybe Bool, or (>) vs liftM2 (>) on Maybe Int.