From: Ian on
On 19 Maj, 13:25, miguel sofer <mso...(a)users.sf.net> wrote:
> 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
From: MartinLemburg on
Hi Miguel,

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...(a)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...(a)gmail.com> napisa³/a:
>
> >>   % 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.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

From: MartinLemburg on
Hi ZB,

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...(a)ispid.THIS-NOcom.pl> wrote:
> Dnia 19.05.2010 MartinLemburg(a)Siemens-PLM <martin.lemburg.siemens-...(a)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.
>
> 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

From: Alexandre Ferrieux on
On 19 mai, 13:58, "MartinLemburg(a)Siemens-PLM"
<martin.lemburg.siemens-...(a)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
From: Bruce on
ZB wrote:
> Dnia 19.05.2010 MartinLemburg(a)Siemens-PLM <martin.lemburg.siemens-plm(a)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