Maybe a, The Rationale
|
View:
New views
19 Messages
—
Rating Filter:
Alert me
|
 |
Maybe a, The Rationale
by PR Stanley
::
Rate this Message:
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. :-) Cheers, Paul _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Thomas Davie
::
Rate this Message:
On 11 May 2008, at 00:36, PR Stanley wrote: > 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. :-) 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. Bob _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by PR Stanley
::
Rate this Message:
>> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by pweaver
::
Rate this Message:
On Sat, May 10, 2008 at 3:56 PM, PR Stanley <prstanley@...> 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. Here's one simple example that popped into my head... maybeHead :: [a] -> Maybe a maybeHead [] = Nothing maybeHead (x:xs) = Just x >> 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? > See the 'lookup' function ( http://haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html#v%3Alookup ) or just abut any other function on Hoogle that uses a Maybe type. > Cheers, Paul > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@... > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Brandon S. Allbery KF8NH
::
Rate this Message:
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@... system administrator [openafs,heimdal,too many hats] allbery@... electrical and computer engineering, carnegie mellon university KF8NH _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by PR Stanley
::
Rate this Message:
>>>> 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. Cheers, Paul _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by pweaver
::
Rate this Message:
On Sat, May 10, 2008 at 3:10 PM, PR Stanley <prstanley@...> 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. > > Cheers, Paul > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@... > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Sebastian Sylvan
::
Rate this Message:
On Sat, May 10, 2008 at 11:36 PM, PR Stanley <prstanley@...> wrote: Hi folks Sometimes you want to express things that can either be a value, or nothing. In some languages all or most "values" (using that term loosely) can be "nullable". E.g. in C# any reference can be nullable, so you can just return null to signify "no value" (e.g. when looking someting up in a dictionary). The problem with this is that every single dereference can no potentially cause a runtime error, which pushes a whole lot of problems to the runtime, when they really could be statically eliminated at compile time. Most functions, after all, really do need all their parameters to "exist" and aren't defined for null, and they really do return a result and never null, so it's useful to know for sure that a "Map Int String" really is a map, and not "null", while you still have the ability to deal with "optional" values in the tiny minority of cases that need it. Also, since it's impossible to actualy use a value without inspecting the constructors of Maybe, you avoid even more runtime errors (unless you use things like "fromJust"). 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... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Brandon S. Allbery KF8NH
::
Rate this Message:
On 2008 May 10, at 20:41, Philip Weaver wrote: > On Sat, May 10, 2008 at 3:10 PM, PR Stanley <prstanley@...> > wrote: >>> >>> 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. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@... system administrator [openafs,heimdal,too many hats] allbery@... electrical and computer engineering, carnegie mellon university KF8NH _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Eric Stansifer-2
::
Rate this Message:
> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Lars Viklund
::
Rate this Message:
On Sun, May 11, 2008 at 02:59:32AM +0100, Eric Stansifer wrote:
> 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. You may want to take a peek at the Boost.Optional [1] library in C++, which provides a lovely Maybe-like class template called "optional". [1] http://www.boost.org/doc/libs/1_35_0/libs/optional/doc/html/index.html -- Lars Viklund | zao@... | 070-310 47 07 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Ketil Malde-5
::
Rate this Message:
PR Stanley <prstanley@...> writes:
> What is the underlying rationale for the Maybe data type? It is the equivalent of a database field that can be NULL. > is it the safe style of programming it encourages/ Yes. Consider C, where this is typically done with a NULL pointer, or Lisp, where you use the empty list, nil. These are perfectly good values in themselves, while Nothing is just Nothing, if you pardon the pun. -k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by PR Stanley
::
Rate this Message:
>>>> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Brandon S. Allbery KF8NH
::
Rate this Message:
On 2008 May 11, at 5:09, PR Stanley wrote: >>>>> 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! :- 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). 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. Maybe types force you to deal with it, while simultaneously providing convenience functions to help you deal with it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@... system administrator [openafs,heimdal,too many hats] allbery@... electrical and computer engineering, carnegie mellon university KF8NH _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Richard A. O'Keefe
::
Rate this Message:
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@... > system administrator [openafs,heimdal,too many hats] allbery@... > electrical and computer engineering, carnegie mellon university > KF8NH > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@... > 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.) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Don Stewart-2
::
Rate this Message:
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) -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by Brandon S. Allbery KF8NH
::
Rate this Message:
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@... system administrator [openafs,heimdal,too many hats] allbery@... electrical and computer engineering, carnegie mellon university KF8NH _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale
by PR Stanley
::
Rate this Message:
> 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. > > is it the safe style of programming it encourages/ > >Yes. Consider C, where this is typically done with a NULL pointer, or >Lisp, where you use the empty list, nil. These are perfectly good >values in themselves, while Nothing is just Nothing, if you pardon the >pun. > >-k >-- >If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@... http://www.haskell.org/mailman/listinfo/haskell-cafe |
|
|
Re: Maybe a, The Rationale |
