A little list/dict bug?
Ian
Unexpected behaviour (for me at least!):
% set a [list 1 b 1 c 2 a]; dict exists $a 1; set a
1 c 2 a
% set tcl_patchLevel
8.5.8
"Looking at" a list as a dict seems to be modifying the list...
Is this a bug?
cheers,
Ian
ZB
> % set a [list 1 b 1 c 2 a]; dict exists $a 1; set a
> 1 c 2 a
> % set tcl_patchLevel
> 8.5.8
>
>
> "Looking at" a list as a dict seems to be modifying the list...
And do you know, what is most interesting? That it depends on the notation:
#v+
% set a [list 1 b 1 c 2 a]; dict exists $a 1; set a
1 c 2 a
% set b [list 1 b 1 c 2 a]
1 b 1 c 2 a
% dict exists $b 1
1
% set b
1 b 1 c 2 a
% set c [list 1 b 1 c 2 a]; dict exists $c 1
1
% set c
1 c 2 a
% set d [list 1 b 1 c 2 a]
1 b 1 c 2 a
% dict exists $b 1; set d
1 b 1 c 2 a
%
#v-
As you can see, the problem occurs only in case, when assigning a list and
checking the existence of dictionary are in one line.
Tested in 8.6.b1.
--
Zbigniew
MartinLemburg@Siemens-PLM
A dict(ionary) can contain only one value per key, so if a list is
treated as dict(ionary) containing more than one value per key, the
last key/value pair is used.
Thus ...
set list {a 1 a 2 b 3 b 4}
... used as dict(ionary) ...
set dict [dict create {*}$list]
... will create not the same data:
% set list
a 1 a 2 b 3 b 4
% set dict
a 2 b 4
As long no multi-key dictionary will be introduced, this behavior is
completely wanted and correct!
Best regards,
Martin Lemburg
On 19 Mai, 11:47, ZB <zbTHIS...@ispid.THIS-NOcom.pl> wrote:
> Dnia 19.05.2010 Ian <i.d.braithwa...@gmail.com> napisa³/a:
miguel sofer
ZB
> This behavior is completely ok!
>
> A dict(ionary) can contain only one value per key, so if a list is
> treated as dict(ionary) containing more than one value per key, the
> last key/value pair is used.
I think you completely missed two points:
1. That "dict exist" seems to be something, that has influence on data -
while, actually, it should have only been an "examining tool", and nothing
more.
2. That it depends on the way, you write it: all in one line, or split into
three verses.
Or is it me, who's missing something?
From the manual:
#v+
dict exists dictionaryValue key ?key ...?
This returns a boolean value indicating whether the given key (or path of
keys through a set of nested dictionaries) exists in the given dictionary
value. This returns a true value exactly when dict get on that path will
succeed.
#v-
There's nothing about changing the list's/dict's contents - be it properly,
or improperly built. Yes: a dictionary should have unique keys - but still
there's a question, why it has been "fixed" by "dict exists" (and why only
in the case, when it was in the same line, as initial "set [list ...]").
--
Zbigniew
Ian
> Verified, opened bug #110894:https://sourceforge.net/tracker/?group_id=10894&atid=110894
>
> Thx
> Miguel
Thanks Miguel and ZB - nice to know I'm not (necessarily) going mad!
Ian
MartinLemburg@Siemens-PLM
why this is a bug?
tcl shimmers "always"!
Using "string is list" on a dictionary changes the internal
interpretation to a list, etc.:
% interp alias {} rp {} ::tcl::unsupported::representation
rp
% set d [dict create a 1 b 2]
a 1 b 2
% rp d
value is a parsedVarName with a refcount of 7, object pointer at
01F34158, internal representation 00000000:00000000, string
representation "d".
% rp $d
value is a dict with a refcount of 3, object pointer at 01F7D270,
internal representation 01FCE550:01F7DD68, string representation "a 1
b 2".
% string is list $d
1
% rp $d
value is a list with a refcount of 3, object pointer at 01F7D270,
internal representation 01FB7E18:00000000, string representation "a 1
b 2".
% string range $d 0 2
a 1
% rp $d
value is a string with a refcount of 3, object pointer at
01F7D270, internal representation 01FE5110:00000000, string
representation "a 1 b 2".
% dict exists $d a
1
% rp $d
value is a dict with a refcount of 3, object pointer at 01F7D270,
internal representation 01FCEAD0:00000000, string representation "a 1
b 2".
And shimmering a list value into a dict value containing "multiple"/
duplicated keys causes changes, or the list value couldn't be
converted into a valid dict value.
If the definition of a valid dict value will be changed to be able to
contain duplicated keys, but only the last defined key would be
accessed with the dict API, than "dict exists" is not allowed anymore
to change the list value, while shimmering!
So ... where is the bug?
In shimmering the value without really accessing the data and so with
out the need to convert? (a currently not valid definition of "dict
exists", because it changes the data type to test if an access is
possible, instead of testing if the given data is usable as dict
(string is list && llength % 2 == 0) and containing the given key name
at an even index)
In the definition of a dict(ionary) to don't tolerate duplicate keys
and to hold only the last key definition on duplicate keys?
Best regards,
Martin
On 19 Mai, 13:25, miguel sofer <mso...@users.sf.net> wrote:
> Verified, opened bug #110894:https://sourceforge.net/tracker/?group_id=10894&atid=110894
>
> Thx
> Miguel
>
>
>
> ZB wrote:
> > Dnia 19.05.2010 Ian <i.d.braithwa...@gmail.com> napisa³/a:
> > Tested in 8.6.b1.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -
MartinLemburg@Siemens-PLM
I did miss the point, because I'm so used to "shimmering", that I
already expected this behavior!
Shimmering occurs so often and unexpectedly, but also silently without
doing any harm, that I do not think about it anymore - normally.
There is a thread in comp.lang.tcl, where I claim about shimmering,
but I learned, that this is nothing "to claim" about, even if it can
cause deep troubles.
So - I think you are right - the data must not change, if only
"testing" dict functionality is used on, but must be changed, if
accessed as dict to extract/change data.
So (2nd) - the problem using a list as dict and not expecting such
change will not vanish, because if the key exists, the key should be
accessed and the list will be changed/shimmered into a dict, that CAN
NOT contain duplicate keys.
No matter how - this problem is ugly, but not really a problem with
the current principle of shimmering and the current concept of the
dict(ionary).
Best regards,
Martin
On 19 Mai, 13:32, ZB <zbTHIS...@ispid.THIS-NOcom.pl> wrote:
> Dnia 19.05.2010 MartinLemburg@Siemens-PLM <martin.lemburg.siemens-...@gmx.net> napisa³/a:
MartinLemburg@Siemens-PLM
once again a thread is discussing about shimmering!
This time especially about shimmering while only examining/testing
data.
The concrete question is, if implicit shimmering with data changing
side effects (non-equal string representation) is really allowed??!!
Is altogether really needed and wanted or simply a side effect, that
e.g. the "string is ..." (sub)commands shimmer the value given?
And what is about commands that extract data, not changing the data,
like "string range" or "dict get":
% string range [set double [expr {double(1.0)}]] 0 0
1
% dict get [set list [list a 0 a 1 b 2 b 3]] a
1
Both examples work on the value, not on a value storage (a variable),
so is it really useful and needed to change the type the value inside
the variable used to "extract" data. (surely for memory allocation
purpose, because always copying data before changing it, is not that
nice, right?)
String commands could use, without any shimmering, the string
representation! (currently not, because the string representation is
not complex enough to support encodings, right?)
Dict commands could work with the last defined key in a series of
duplicated keys! (not that nice for performance reasons, right?)
And so on.
I know that I draw a very plain picture, but I think that this
discussion is necessary, because just this "dict exists" example,
where the implicit shimmering has data changing site effects, shows
the dangerous side of shimmering!
Best regards,
Martin
On 19 Mai, 13:58, "MartinLemburg@Siemens-PLM"
> > - Zitierten Text anzeigen -- Zitierten Text ausblenden -
Alexandre Ferrieux
<martin.lemburg.siemens-...@gmx.net> wrote:
> Hi Miguel,
>
> why this is a bug?
> tcl shimmers "always"!
>
Because shimmering is only an aspect of underlying data (the internal
rep), while the semantics of Tcl values is strictly defined by their
(extended UTF8) string representation.
So yes, shimmering is allowed, but it does not have the right to
discard the string rep !
Only a direct change to the value (like [dict set], [incr], [lappend])
can do that. In that case the internal rep is updated and the string
rep discarded; later on a new string rep may be requested and
computed. That's the essence of the Tcl_Obj internal representation
cache, which by design always respects EIAS.
-Alex
Bruce
> Dnia 19.05.2010 MartinLemburg@Siemens-PLM <martin.lembur...@gmx.net> napisaďż˝/a:
>> This behavior is completely ok!
>>
>> A dict(ionary) can contain only one value per key, so if a list is
>> treated as dict(ionary) containing more than one value per key, the
>> last key/value pair is used.
>
> I think you completely missed two points:
>
> 1. That "dict exist" seems to be something, that has influence on data -
> while, actually, it should have only been an "examining tool", and nothing
> more.
no read the docs carefully
>
> 2. That it depends on the way, you write it: all in one line, or split into
> three verses.
this is an issue
>
> Or is it me, who's missing something?
>
yes it is you
> From the manual:
>
> #v+
> dict exists dictionaryValue key ?key ...?
>
> This returns a boolean value indicating whether the given key (or path of
> keys through a set of nested dictionaries) exists in the
<<<<<<< given dictionary value >>>>>>>>>
> This returns a true value exactly when dict get on that path will
> value. This returns a true value exactly when dict get on that path will
> succeed.
> #v-
>
> There's nothing about changing the list's/dict's contents - be it properly,
> or improperly built. Yes: a dictionary should have unique keys - but still
> there's a question, why it has been "fixed" by "dict exists" (and why only
> in the case, when it was in the same line, as initial "set [list ...]").
dict exists is NOT asking is this arbitrary value a dict?
is is aksing given this dict value does this key exist in it.
by calling a dict function you are asking for it to be treated as a dict
the second case that *doesn't* change is the one I don;t understand.
Bruce
Alexandre Ferrieux
wrote:
To be more precise, what happen(ed) here is that a pure-list (no
string rep) was going through the list->dict shortcut without special
care for the loss of information of duplicate keys. This was fixed in
the 8.6 branch by Donal on 2010-02-24, by forcing the computation of
the whole list's string rep as soon as one duplicate key was
encountered. A backport may be indicated if a 8.5.9 is due.
-Alex
Alexandre Ferrieux
Bruce
>> some incorrect stuff....
please ignore my post - i was thinking about the shimmering since
a dict command was used, not the missign/invlaidated string rep
tha should have remained - please read Alex's msgs for correct
info
Sorry,
bruce