Using 8.5 Dict ... huh?
sp...@controlq.com
I'm toying with replacing namespace associate arrays with a dict, and
suffering the requirment for tcl 8.5 for my application, as it is a neat
idea, and offers many advantages over the associative array I've been
using but I'm having some problems getting my head around the use of dict.
I've read the tip, and the man page, and perhaps I've just been staring at
this too long, but here's a little session which is causing me grief ...
tclsh8.5
% set x [dict create 1 one 2 two 3 three]
1 one 2 two 3 three
# ok so far ...
% dict remove $x 2
1 one 3 three
% puts $x
1 one 2 two 3 three
# huh? ok, doc says it returns a new dict ... so
# I'll reset the dict ...
% set x [dict remove $x 2]
1 one 3 three
% puts $x
1 one 3 three
# ok, that's better
% dict set $x 2 two
2 two
% puts $x
1 one 3 three
# hmm ... that didn't work ...
# so I'll re-set x to the result of the operation ...
% set x [dict set $x 2 two]
2 two
% puts $x
2 two
%
# oops ...
at this point, I'd have expected x to be a dict with {1 one 2 two 3 three}
though not necessarily in that order. Perhaps this has just been a long
day, or some subtle scoping issue is eluding me ... and I have yet to
grokk the nested dicts ... any pointers as to what my poor frazzled brain
is failing to discern here?
Cheers,
Rob.
Gerald W. Lester
>
> I'm toying with replacing namespace associate arrays with a dict, and
> suffering the requirment for tcl 8.5 for my application,
There is an 8.4 dict extension you could use.
> as it is a neat
> idea, and offers many advantages over the associative array I've been
> using but I'm having some problems getting my head around the use of dict.
>
> I've read the tip, and the man page, and perhaps I've just been staring
> at this too long, but here's a little session which is causing me grief ...
>
>
> tclsh8.5
>
> % dict set $x 2 two
> 2 two
> % puts $x
> 1 one 3 three
> # hmm ... that didn't work ...
> # so I'll re-set x to the result of the operation ... % set x [dict set
> $x 2 two]
> 2 two
> % puts $x
> 2 two
> %
> # oops ...
Because [dict set] takes the name of a variable holding a dict not a dict.
Try:
% dict set x 2 two
1 one 2 two 3 three
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
sp...@controlq.com
>> # oops ...
>
> Because [dict set] takes the name of a variable holding a dict not a dict.
>
> Try:
>
> % dict set x 2 two
> 1 one 2 two 3 three
Ahhh, the missing link! Thanks Gerald! I'll read more carefully next
time ...
Cheers,
Rob.
Larry W. Virden
> I've read the tip, and the man page, and perhaps I've just been staring at
> this too long, but here's a little session which is causing me grief ...
>
> tclsh8.5
> % set x [dict create 1 one 2 two 3 three]
> 1 one 2 two 3 three
> # ok so far ...
>
> % dict remove $x 2
> 1 one 3 three
> % puts $x
> 1 one 2 two 3 three
> # huh? ok, doc says it returns a new dict ... so
> # I'll reset the dict ..
Because $x is a value, not a name of a variable, dict remove can only
return to you a new entity, and it is your job to put it into some
variable of use.
> % set x [dict remove $x 2]
> 1 one 3 three
> % puts $x
> 1 one 3 three
> # ok, that's better
>
> % dict set $x 2 two
> 2 two
> % puts $x
> 1 one 3 thr
> # hmm ... that didn't work ...
> # so I'll re-set x to the result of the operation ...
On the other hand, the man page says that dict set doesn't take a
_dictionaryValue_, but a _dictionaryVariable_ and then it returns a
dictionaryValue. So you replaced the old dictionary in X, with a new
dictionary.
> % set x [dict set $x 2 two]
> 2 two
> % puts $x
> 2 two
> %
> # oops ...
>
> at this point, I'd have expected x to be a dict with {1 one 2 two 3 three}
> though not necessarily in that order. Perhaps this has just been a long
> day, or some subtle scoping issue is eluding me ... and I have yet to
> grokk the nested dicts ... any pointers as to what my poor frazzled brain
> is failing to discern here?
Notice that these dict commands use variables as an argument:
dict append dict incr dict lappend dict set dict size
dict unset dict update dict with
and these use values as an argument
dict exists dict filter dict for dict get dict info dict keys dict
merge
dict remove dict replace dict size dict values
Frankly, I find this behavior of Tcl to be its most confusing to me -
and dict accellerates the problem by
commands like dict incr and dict filter, which seem to operate counter
to rules that I have tried to generate in my mind to explain how to
remember which subcommands take which.
Cameron Laird
Larry W. Virden <lvi...@gmail.com> wrote:
.
.
.
>Notice that these dict commands use variables as an argument:
>dict append dict incr dict lappend dict set dict size
>dict unset dict update dict with
>
>and these use values as an argument
>dict exists dict filter dict for dict get dict info dict keys dict
>merge
>dict remove dict replace dict size dict values
>
>Frankly, I find this behavior of Tcl to be its most confusing to me -
>and dict accellerates the problem by
>commands like dict incr and dict filter, which seem to operate counter
>to rules that I have tried to generate in my mind to explain how to
>remember which subcommands take which.
I'm sympathetic.
One of the many crutches I employ for my all-too-fallible memory
is to enter
% dict remove
(for example) at a tclsh prompt, and let Tcl itself tell me what
should follow. Larry already knows this, but perhaps others will
find the trick handy.
Keith Nash
> Notice that these dict commands use variables as an argument:
> dict append dict incr dict lappend dict set dict size
> dict unset dict update dict with
>
> and these use values as an argument
> dict exists dict filter dict for dict get dict info dict keys dict
> merge
> dict remove dict replace dict size dict values
>
> Frankly, I find this behavior of Tcl to be its most confusing to me -
> and dict accellerates the problem by
> commands like dict incr and dict filter, which seem to operate counter
> to rules that I have tried to generate in my mind to explain how to
> remember which subcommands take which.
I'm glad I'm not the only one who finds this confusing.
The default in Tcl is to take a value, not a variable name; so there is a
case for defining argument names that will remind us when a variable name
is required - e.g.
dict existsVar
dict incrVar
Keith.
Cameron Laird
Keith Nash <kj...@citizenearth.com> wrote:
.
.
.
>I'm glad I'm not the only one who finds this confusing.
>
>The default in Tcl is to take a value, not a variable name; so there is a
>case for defining argument names that will remind us when a variable name
>is required - e.g.
>dict existsVar
>dict incrVar
>
>Keith.
>
Ewww.
That is, my personal reaction to your summary is ... not favorable.
Are you saying you prefer the standard library defined
incrVar my_loop_counter
rather than
incr my_loop_counter
? I can see that that might indeed decrease the incidence of some
people reporting Tcl as "confusing" for parts of their Tcl careers.
To me, it wouldn't feel like a better language, though.
I suspect we're fairly far into the subjective, at this point.
Most certain for me is that Tcl is very, very unlikely to make these
changes. Perhaps it's time to emphasize again what a mass of legacy
code there is for which the Core maintainers feel responsible.
Kaitzschu
> Larry W. Virden wrote:
>
>> Frankly, I find this behavior of Tcl to be its most confusing to me -
>> and dict accellerates the problem by commands like dict incr and dict
>> filter, which seem to operate counter to rules that I have tried to
>> generate in my mind to explain how to remember which subcommands take
>> which.
>
> I'm glad I'm not the only one who finds this confusing.
And don't forget that some subcommands take multiple keys and some just
one key. Just the other day I had a real blast when I [dict lappend]ed an
expanded {*}$keys with $value and had subdict rendered invalid as it had
uneven count of items. And of course this didn't show up unless path had
even count of keys...
And [dict incr] inside subdicts,
% info patchlevel
8.5a6
% set foo {a {b {c {d {e 1}}}}}
a {b {c {d {e 1}}}}
% dict update foo a t {
dict update t b t {
dict update t c t {
dict update t d t {
dict incr t e
}
}
}
}
e 2
% set foo
Segmentation fault
Yee-haw! As a bonus, [set t] gives just the same. All this just to let
someone use integer keys and keep [incr]ement optional. Just as it is any
longer to write
dict incr foo bar baz 1
than
dict incr foo bar baz
but no can do.
--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
miguel
> And [dict incr] inside subdicts,
> % info patchlevel
> 8.5a6
> % set foo {a {b {c {d {e 1}}}}}
> a {b {c {d {e 1}}}}
> % dict update foo a t {
> dict update t b t {
> dict update t c t {
> dict update t d t {
> dict incr t e
> }
> }
> }
> }
> e 2
> % set foo
> Segmentation fault
> Yee-haw! As a bonus, [set t] gives just the same.
Please do report ALL segfaults to the bug tracker - no way we can fix
bugs we do not know about, and we do consider any segfault a major bug.
This one is now Bug #1786481
(http://sourceforge.net/tracker/index.php?func=detail&aid=1786481&group_id=10894&atid=110894)
> All this just to let
> someone use integer keys and keep [incr]ement optional. Just as it is
> any longer to write
> dict incr foo bar baz 1
> than
> dict incr foo bar baz
> but no can do.
I did not quite understand this.
Kaitzschu
> Please do report ALL segfaults to the bug tracker
I ran into that segfault while writing the rant about my experiences with
[dict lappend], and I was sleepy, and grumpy, and SourceForge doesn't play
nice with ELinks, and <more lousy excuses> ... :)
> Kaitzschu wrote:
>> All this just to let someone use integer keys and keep [incr]ement
>> optional. Just as it is any longer to write
>> dict incr foo bar baz 1
>> than
>> dict incr foo bar baz
>> but no can do.
>
> I did not quite understand this.
I meant
dict incr dictionaryVariable key -> ?increment? <-
with "[incr]ement optional". As that is optional there is no way to
dict incr foo a b 2
since there is no way to know (without looking inside the dict) does this
mean that user wants to increase keypath {a b} by 2 or keypath {a b 2} by
one (default increment). If increment parameter was mandatory this command
could take multiple keys and increment directly inside subdicts. And it
would be just 2 characters longer to write (in default case), hardly a big
difference when actual command is 10 characters plus variable name plus
key path.
But I guess this can't be changed if this command must look like normal
[incr].
Joe English
> [...] bug I'm having some problems getting my head around the use of dict.
>
>I've read the tip, and the man page, and perhaps I've just been staring at
>this too long, but here's a little session which is causing me grief ...
It would appear that most of your grief comes from confusion
over which [dict] subcommands take variable names and which
ones take values. This _is_ confusing, since there doesn't
appear (at first) to be any rhyme or reason to the scheme --
why should [dict set] operate on variables while [dict remove]
operates on values?
Fortunately, the manpage is very careful to distinguish the
two cases and spells out explicitly which one is used
in the synopses, e.g.:
| dict remove dictionaryValue ?key ...?
| dict set dictionaryVariable key ?key ...? value
--Joe English
sp...@controlq.com
When I started programming back in the 1970's, I remember reading an
article written by a seasoned programmer (Bob Green) which said "Read a
manual like a love letter". I simply failed to study the details
sufficiently, and I'm in no way slagging the dict syntax. Personally, as
I get used to dict's, it is likely I'll use them frequently. The syntax
issues will very soon be well behind me, and practice will make adequate.
Cheers,
Rob.
suchenwi
> It would appear that most of your grief comes from confusion
> over which [dict] subcommands take variable names and which
> ones take values. This _is_ confusing, since there doesn't
> appear (at first) to be any rhyme or reason to the scheme --
> why should [dict set] operate on variables while [dict remove]
> operates on values?
Isn't it the distinction whether a subcommand just does read access
(where $dict is enough), or possibly modifies a variable (where the
name must be given)?
Andreas Leitgeb
Yes, that's exactly the difference.
But, just from the subcommand's name you cannot really guess
which of these two models it follows.
For read-access, it is of course guessable,
but for modifying commands, you don't know, if the
the modification happens inplace (variable), or if
a modified object is returned.
Jonathan Bromley
>But, just from the subcommand's name you cannot really guess
> which of these two models it follows.
>
>For read-access, it is of course guessable,
>but for modifying commands, you don't know, if the
>the modification happens inplace (variable), or if
>a modified object is returned.
This has been with us since forever. [lappend] and
[lreplace] make a nice example of the problem;
it's caused me (and students) endless pain. But
I don't see any way around it, unless you have
much more verbose command names.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.