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

[Neil M. <ne...@Cs...>]

On 16 Jun 2008, at 11:59, Fredderic Unpenstein wrote:
> Actually, my point is that that all works only so long as you're
> religious in your use of [Nothing] and [Some] (Wasn't it [Just]?) when
> examining and producing values.  You need to do extra work not only in
> your function to test for it, but also in any function from which you
> obtained that value.  And if you want to write the non-null value to
> the user, you need to unwrap it first.  Worst of all, is that any
> function that wants to store or return a NULL forces every function
> that uses that value to test for it.

*EVERY MEANS OF INDICATING UNKNOWN INFORMATION REQUIRES YOU TO TEST  
FOR IT*! If you are indicating missing/unknown information in your  
program but not ever testing for that or handling it, then you have a  
bug in your program. Plain and simple. If you use a NULL pointer,  
then you have to have to explicitly return a NULL pointer and you  
have to explicitly test for NULL when using it. How is this in any  
way different to the maybe datatype or any other mechanism for  
representing a lack of information? Indeed, I quite clearly already  
demonstrated a one-to-one correspondence between a C pointer and the  
maybe datatype:

   [Just $a]  <==> &a
   [Nothing]  <==> NULL
   if {[maybe exists $foo v]} { puts $v } <==> if (foo != NULL) { v =  
*foo; printf("%s\n", v); }

I also provided a C implementation that implements this precisely as  
a C pointer, and I provided a convenience command (exists) that does  
the test and the extraction in one go (something not even possible in  
C). I furthermore also provided earlier a demonstration of how even  
this minimal testing can be abstracted into a pair of commands (the  
"monad" stuff) that allow you to compose together operations without  
ever having to do an explicit check for [Nothing] in your application  
code! This is so far *beyond* what is possible in C using a NULL  
pointer or the bad joke that is SQL that I'm frankly staggered that I  
still have to defend it to professional programmers. Even if you  
never use that code, I would at least expect that you acknowledge  
that is more than a match for a fscking NULL pointer.

> (I have to say also, I seriously hate those names.  They need at least
> to be rolled into one command with sub-commands.  The [maybe exists]
> command is kinda neat, though.)

They are all part of the [maybe] command -- [maybe Nothing], [maybe  
Just], [maybe exists]. I just prefer to [namespace import] the data  
constructors for convenience. You can rename them whatever you want.  
ML uses the names "SOME" and "NONE" for the equivalent datatype:  
datatype 'a option = SOME of 'a | NONE.

> That is one of the two classes of NULL I pointed out.  It's portable,
> but requires extra work in every single piece of script it touches.
> What was the word for that, again...?  It was used in relation to
> NULLs (specifically in their evil-unicode implementation) rendering
> strings they were embedded within also invalid.  The thing I really
> don't like, though, is that [nothing foo] is indistinguishable (as you
> just demonstrated however otherwise unnecessarily) from [list 0 foo].
> That concerns me, and has done throughout this discussion, because
> it's also indistinguishable from "0 foo" for any purpose for which
> this idea might be preferred over the magic-value NULL types.

The special value NULL in C is indistinguishable from the integer 0  
if you don't have the type system to help you out. This is precisely  
why trying to solve any problem in terms of special representations  
is a very bad idea -- what matters is interpretation, not  
representation. In other words, if your application is expecting a  
"maybe" value, then it can reliably distinguish between Nothing and  
[Just $data]. Likewise, if it is expecting a pointer (in C) then it  
can reliably distinguish between NULL and a valid pointer. If it  
isn't expecting these things and you pass it one anyway (or if it is  
expecting one, and you pass it something else), then you are in  
trouble -- in precisely the same way you'd be in trouble if you pass  
a non-list to a proc that expects a list or the path of a file to a  
proc that expects an open file channel. The idea that introducing a  
special NULL value would allow you to pass it around to whatever  
command you like without ever checking it is utterly wrong, and is  
precisely the kind of sloppy programming that causes so many problems.

Frankly, at this point, it is put up or shut up time. I for one am  
sick of these discussions, and I suspect a good portion of the Tcl- 
Core audience is too. If you have a serious suggestion for how  
unknown information should be handled in Tcl then write some notes  
(if it is a simple convention), write some code, or, as a last  
resort, write a TIP. I simply don't need to argue these points, as  
I'm pretty confident that the majority of the voting TCT is fully  
aware of the issues and how (not) to address them.

-- Neil

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.