>> "But null pointers can be useful!" I hear you cry. For this, Haskell has
>> the "Maybe" type. Basically, if you say "Foo", it will definitely,
>> always, be a Foo. But if you say "Maybe Foo", then it may or may not be
>> a Foo - and the type system *requires* you to explicitly check whether
>> it's "null" or not before you do stuff to it.

Incidentally, this is the general theme with Haskell. Other languages 
signal an error by returning a null pointer, or if the result is 
supposed to be an integer, returning a zero or a negative or something. 
Haskell style is to use ADTs to return something more high-level. This 
way, the possibility of failure is explicitly signalled in the type 
system, and the type system will complain if you fail to explicitly 
check for failure.

(And then you get to the point where you can perform several 
possibly-failing operations in sequence, and have the sequence 
automatically abort at the first failure, whichout having to write a 
bunch of failure-checking code for each and every failure. It's almost 
like an exception, except that it's regular program data, rather than a 
special "magical" flow control construct...)

>    It sounds a bit like references vs. pointers in C++: References in C++
> cannot be null, they always have to point to an actual object.

Sounds potentially quite useful.

>    Of course the limitation with C++ references is that they are const:
> You cannot modify a reference to point to another object.

Sounds a lot like Haskell...

> (I'm not exactly sure now why this was deemed as necessary.)

Nor am I, but hey.

Maybe they were worried that you could make a reference point to 
something dynamic, and then free that something, leaving a dangling 
reference?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message