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

[Fredderic U. <mag...@gm...>]

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.

(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.)

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 other class of NULL which I personally like, takes no extra work
unless you're specifically interested in it, and even then it's a
simple and very efficient test in the receiver.  If you ignore it,
then it's just the empty string (or whatever else you want it to look
like).  The only place it would need any extra work, is in
transferring it across shimmer boundaries (of which there are more
than there should be).


Personally, I'm somewhat torn on this issue myself.  I hate that the
[maybe] approach requires so much extra work to manage; even just to
display the value, you have to rip it out of its wrapping first.  And
putting extra work into the script to handle a fundamental concept
isn't a good thing, IMHO.  Honestly, I don't see it as being much
better than simply using [list] and [llength] (even the fact that you
can name your NULLs probably makes the issue worse in this instance!).

On the other hand the magic-value NULLs are distinctive from ANY other
value.  It either is a NULL, or it isn't.  BUT, you do have to be
careful to avoid letting it shimmer, and there are still a few
occasions where TCL will shimmer things it doesn't really need to.


Fredderic

On 16/06/2008, Alexandre Ferrieux <ale...@gm...> wrote:
> On 6/15/08, Fredderic Unpenstein <mag...@gm...> wrote:
>>
>> 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.
>
> No, you missed the point.
>
> The Maybe method (be it implemented with Neil's package, with Cons, or
> wit hplain 2-element lists) encodes the nullity of a value
> out-of-band:
>
> (example with 2-element lists as it is doable in pure Tcl)
>
>      Nothing == {0 whatever}
>      Some foobar == {1 foobar}
> for any $x
>      Some $x ==[list 1 $x]
>
> You can see that no $x this side of the universe will swallow the "1 "
> prefix (since you're talking about string reps).
>
> -Alex
>