Re: [TCLCORE] ANN: maybe package for null handling

[Twylite <tw...@cr...>]

Hi,
> From: "Fredderic Unpenstein" <mag...@gm...>
>   
> The most common implementation of a true NULL in todays TCL, is the
> unset variable.  I'm pretty sure we ALL use [info exists] from time to
> time.  That's a very real form of NULL, so arguing that NULLs are evil
> is about as logical as making [info exists] always return 1, and
> auto-initialise all variables in all uses.  After all, who ever heard
>   
Sorry, that's a strawman.  A NULL is more than something missing.  An 
incorrect but more workable description would be a reference to 
something that is missing.  The distinction is all important: it is easy 
to review code (static checking, whether manual or automatic) to ensure 
that you don't attempt to access something that is missing (trying to 
get $a where a is not set in the scope), but trying to prove that your 
code never dereferences a reference to something that is missing is a 
lot harder (and requires global knowledge, not just local knowledge).
> NULL internal to TCL, to see why that's a bad idea.  The first
> argument that crops up every time, is "but you'd need to check for it
> everywhere" (which translates roughly to "that sounds like too much
> hard work for us").  Mind you, I'm not saying that's an invalid
> argument, but then in the same breath those same people all say, "but
> it's okay if YOU do twice as much work to somehow wrap any value that
> MIGHT be null in an ad-hoc per-instance and vastly more wasteful
>   
It's not about work.  It's about safety.  If something can blow up when 
you dereference it then you must add checks to ensure that it can't blow 
up _before_ you dereference it.

Look at any C coding checklist, and one of the items will be "check all 
return values for errors and all returned/out pointers for NULL".  We 
don't have to do that in Tcl, because we (1) have exceptions and (2) 
don't have NULL.  This means that Tcl allows you to concentrate on the 
code that does stuff, and dispense with the syntactic & error handling 
noise.

And you cannot, ever, do that if you have NULLable references in a language.
> And there again.  What is a C NULL anyway...?  Interestingly, it's a
> regular value, just like any other value.  It's nothing more than the
> number 0.  It could have just as easily been 1 or 3.  What makes this
> one special, is that it's linked to a very specific concept.  The
> concept of a piece of physical silicone that we agree not to be used
> for any other purpose.  (In actual fact, even that's not entirely
>   
No, it's not a regular value.  It is a specific value of _a pointer_.  
An int in C cannot be null.  Nor can any other numeric value.  A string 
can but only because strings are implemented in terms of pointers.  In a 
language without pointers or references, NULL makes no sense.
And I've dealt with at least one embedded platform where NULL is not 0. 
> How do the [cons] or [list] based methods achieve this?  By using some
> value that they hope no one else will use.  But what to do if some
> piece of script comes along and wants to return a string that just
> happens to look like the string rep of your [cons] and [list] methods.
>   
What?  Have you actually read NEM's description of the Maybe monad?
> representation), which we refer to as NULL.  [cons] and [list] simply
> don't provide that in a general context.  The {}{} (and similar)
>   

The idea of using cons / pairs is to return two pieces of data - a 
status (if one can call it that) and a return value.  Put another way, 
every return have in-band return data and an out-of-band status.  Put 
yet another way, this is the way that the whole of Tcl works - a return 
value (indicating return, error, break, continue, etc) and a result 
object.  What exactly is lacking about them?

Regards,
Twylite