gmane.comp.lang.haskell.cafe

Thomas Davie | 11 May 00:49

Re: Maybe a, The Rationale

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

headers

PR Stanley | 11 May 00:56

Re: Maybe a, The Rationale


>>         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

headers

Philip Weaver | 11 May 01:02

Re: Maybe a, The Rationale

On Sat, May 10, 2008 at 3:56 PM, PR Stanley <prstanley <at> ntlworld.com> 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

(Continue reading)

headers

Brandon S. Allbery KF8NH | 11 May 01:04

Re: Maybe a, The Rationale


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

(Continue reading)

headers

PR Stanley | 11 May 01:10

Re: Maybe a, The Rationale


>>>>        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

headers

Philip Weaver | 11 May 02:41

Re: Maybe a, The Rationale

On Sat, May 10, 2008 at 3:10 PM, PR Stanley <prstanley <at> ntlworld.com> 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

(Continue reading)

headers

Brandon S. Allbery KF8NH | 11 May 03:27

Re: Maybe a, The Rationale


On 2008 May 10, at 20:41, Philip Weaver wrote:

> On Sat, May 10, 2008 at 3:10 PM, PR Stanley <prstanley <at> ntlworld.com>  
> 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 <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH

headers

PR Stanley | 11 May 11:09

Re: Maybe a, The Rationale


>>>>         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

headers

Brandon S. Allbery KF8NH | 11 May 15:52

Re: Maybe a, The Rationale


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

(Continue reading)

headers

Richard A. O'Keefe | 12 May 04:20

Re: Maybe a, The Rationale

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

(Continue reading)

headers

Don Stewart | 12 May 04:42

Re: Maybe a, The Rationale

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

(Continue reading)

headers

Brandon S. Allbery KF8NH | 12 May 05:10

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
>

(Continue reading)

headers

Sebastian Sylvan | 11 May 03:03

Re: Maybe a, The Rationale

On Sat, May 10, 2008 at 11:36 PM, PR Stanley <prstanley <at> ntlworld.com> 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.
Cheers, Paul

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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

headers

Eric Stansifer | 11 May 03:59

Re: Maybe a, The Rationale

> 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

headers

Lars Viklund | 11 May 04:24

Re: Maybe a, The Rationale

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 <at> acc.umu.se | 070-310 47 07

headers

Ketil Malde | 11 May 11:01

Re: Maybe a, The Rationale

PR Stanley <prstanley <at> ntlworld.com> 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

headers

PR Stanley | 13 May 23:35

Re: Maybe a, The Rationale


>         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

headers

Jules Bean | 14 May 15:49

Re: Maybe a, The Rationale

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.