Tcl Source Code

This is a first hack at compiling the [dict] command.
It passes the test suite cleanly for me (clock.test is
a pretty good workout of many of the features that are
compiled.)

Logged In: YES 
user_id=79902

the dict compiler has been in the HEAD for a while now

Logged In: YES 
user_id=79902

By automatic variable, do you mean a local temporary Var or
a C variable or what?

Storing the Tcl_DictSearch in the bytecode structure won't
work because of recursion. Putting the value in a
(stack-allocated) C variable could work, but it'd be tricky
to get right because you can nest iterations (and we really
want to reduce the amount of stack space required for TEBC
anyway) which means you'd have to keep an array (or list) of
them; you could do it, but it'd be a lot of work to get
right (not that we couldn't do this in the future, of
course, but it would break the TDK compiler if we did it
whereas my current solution remains compatible on this front
at least). The easiest way is to store the iterator context
in a Var, since they're handled right anway, which is what I
do. :^)

Logged In: YES 
user_id=80530

Um, ignore my last comment.

Clearly nested [dict for] commands
will compile to a stream of bytecode
that would execute in many iterations
through TEBC, but not nested TEBC
calls.  Dynamic allocation is correct.

Logged In: YES 
user_id=80530


line 5076 of tclExecute.c
dynamically allocates a
Tcl_DictSearch.  Any reason
not to use an automatic variable
instead?

File Deleted - 141861: 



File Added - 142041: bccDict_2.diff

Logged In: YES 
user_id=79902

Here's an updated patch that includes compilation of [dict
append] and [dict lappend] as well.

Logged In: YES 
user_id=79902

1: wordTokenPtr[0].type is correct (but better written as
wTP->type). I didn't write the way tokens operate...
2: I hadn't thought of doing that, but it's not a major
issue. I do worry about having a table of subcommands in two
locations though.
3: I'm trying to ensure that the compilation works, and
extending coverage to all possible prefixes is a low-value
issue, since it is Good Practice to not rely on prefixes at all.
4: I'm not going to do anything about this in this patch.
5: It's a cargo-cultist copying from the [incr] compiler.
i.e. yet another thing to fix outside the context of this
patch :-)

Logged In: YES 
user_id=80530


I don't see the value of the
TclLooksLikeInt() call in
the compile of [dict incr].
It tells us approximately whether
we have an int value, by at
least rejecting string that
do not "look" right.

If it passes, we move on to
an actual Tcl_GetIntFromObj()
call which tells us for sure whether
we have an int value.

I don't see the point of a half-test
right before the real test.  I suppose
it could help us fail faster, but is
that really important?  The check
also makes us succeed slower,
and success ought to be the normal
mode.

Logged In: YES 
user_id=80530


This is true about pre-existing code
as well, but might as well mention it:

The variable name "nameChars" is
misleading as the value it holds is
a number of bytes, not a number of
characters.  Would be a good idea
to change them all.

Logged In: YES 
user_id=80530


I note that the direct evaluation
implementation of [dict] does
accept unique prefixes, so it seems
strange that the [dict] compiler
refuses to compile them.  That
suggests to me that copying
the [string] compiler routine is
the way to go.

Logged In: YES 
user_id=80530


On the subcommand parsing
topic, I note that the [string]
compiler accepts unique prefixes
of subcommands for compiling
([string comp] for example).  Will
have to consider whether the
[dict] compiler will copy that.

Logged In: YES 
user_id=80530


I'm a bit surprised to see
TclCompileDictCmd use
repeated strncmp() calls
for subcommand parsing.

Wouldn't it make more sense
to copy TclCompileStringCmd()'s
technique of using Tcl_GetIndexFromObj() ?

If not, does it make sense to do the
reverse, and have the [string] subcommands
parsed as the [dict] ones are?

I think it would be best not to use two
different techniques in the same
source code file without a really
good reason.

Logged In: YES 
user_id=80530


On line 2774 of the patched
tclCompCmds.c, shouldn't

(wordTokenPtr[0].type == TCL_TOKEN_SIMPLE_WORD)

be

(wordTokenPtr[1].type == TCL_TOKEN_SIMPLE_WORD)

?

File Added - 141861: bccDict.diff