Re: [TCLCORE] Empty list is not a list -- using twoPtrValue for NULL type

[Alexandre F. <ale...@gm...>]

Hi Neil,

> Hehe, I like a bit of red flag waving sometimes... (bit "Old Labour" me).

:-)))

> Seriously, though, I raise these issues in the hope of fleshing out the
> proposal and exploring alternatives, rather than just to shoot you down.
> I'm not keen on making the above a possibility if we can avoid it, as while
> it can be sensibly avoided I worry that lesser scenarios might happen by
> accident.

I understand. Your arguments do hit their target by the way. Here is
an attempt to synthesize:

   (1) The primarily aim is to reach and modify in-place deeply buried
substructures;

   (2) Variables are of course the only truly Tclish way of doing this ;

   (3) However, we don't have (yet) a simple way of "upvarring" into a
5th-level subtree of a dict/list tree (but see below);

   (4) While I find it very easy in comparison, to introduce
mutability on values, despite the fully acknowledged fact that it
violates previous "principles"; a powerful tool, but not for babies,
like setjmp()/longjmp() in C... And a pretty high (range of
possibilities)/(lines of code) ratio !

Now, let's look in more detail at your proposal.
You said:

> Right, but as I showed in the other message, you can quite easily place a
> fully-qualified variable name inside a nested structure and confine the
> mutability right there. It's not a perfect technique by far, but it has
> some advantages.

OK, but that's not transparent. The tree is transfigured by the
operation, since it is no longer traversable by simple foreach / dict
foreach (you need to dereference at each level you think you'll ever
need mutability).

>> [vars-with-paths]

> That is a good idea. Doesn't even need to be syntax, a command could
> probably do it:
> update cmd path var
> e.g.:
> update incr {l 2 d c l 2} x

OK, in the spirit of [dict update]. From the script POV it is nice.
But how would this be implemented ?
What kind of internal API is needed between tclListObj.c and
tclDictObj.c to allow for an arbitrary mix of l and d above ? What
about future new containers ?

Also, what about the precise handling of the refcount of the updated
substructure ?As mentioned in the clt thread, a possibility would be
to temporarily secure it from the enclosing structure after binding it
to "x" (so that it stays unshared and can efficiently be modified
in-place). But would you really do this ? Wouldn't it be a surprise
if, within "cmd", someone wanted to look again at the contents of the
enclosing structure (a kind of "blind spot" effect) ?

-Alex