'''[PWQ]''' ''29/01/04''

With a casual look through the code, there seems to be at first glance only a small amount of effort to give access to [dict] types using the array notation.

What some people desire is the following:
	set fred [dict create A 1 B 2]
	puts "B = $fred(B)"
	puts "fred is a $fred"

While there are pro's and cons to both sides for and against. It could only be a good thing if variables,lists,arrays,  and now dicts interoperate as much as possible to limit the number of ways data is accessed.

One option would be to deprecate the use of ''$var'' which would be one way to reduce the number of different data access methods, by enforcing  the use of [[type get]] notation for all.

Assuming the above is not a contender, then another simple change would be to modify Tcl_GetVar2 and cousins.

At the moment if a reference in the form of $''name''(''element'') finds that ''name'' is a scalar, then an error is thrown.
It would be simple at this point to add a test to see if the scaler is of type DICTIONARY. The code can then fall through to return Tcl_DictGet (or similar). 

I suspect that in the Byte compiler it is not that simple, my comment would be ''Too freaking bad''. Any complications caused by the BC should NOT be used as arguments against evolution of the language. 
''([MS] agrees fully, but cannot recall any instance of that argument being used, and does not think the [TCT] would even consider it.)''

If we were to accept the above is trivial and feasible, and apply proactive design methodologies (rather than the normal reactive ones the TCT uses ''([DKF]: Most of the [TCT] are not paid to do core work, so they are constrained in what they can do.)''), we would at this point replace the test for DICTIONARY with instead an installable subsystem that could implement more than just dictionaries, and only add a few extra commands to the tcl core in the process.

Before embarking on a discussion of the above, one should first determine the frame of reference for what the considerations should be.
For example:
   * Does the change enhance the language.
   * Is there a use for implementing the change.
   * What negative impacts on the language does the change create.
   * Could the change be incorporated into further core parts and thus simplify other aspects of data access.

My evaluation of the above, shows that the pro's significantly outway the cons.

I could at this point extend the changes to include such things as array shadowing, persistant stores, but I am sure the above is contentious enough to ensure a resounding '''NO'''.

30jan04 [jcw] - Philip, my understanding of OSS in general and Tcl in particular, is that it is usually not possible to get consensus ''up front'', i.e. with proposals which can be subject to interpretation and mis-understanding.  The way to get things done IMO is to build it, or work with colleagues who want to do it for/with you, then share the results and respond to Q's and adjust things where you feel the points made are valid, and ''then'' stand up and make your case on why/how it should go into the core.  This is how stubs and VFS went in (not that long ago, btw).  I'm afraid you won't find many people to scratch your itch by filing a generic complaint - then again, I may well be wrong... I'm just trying to encourage anyone who wants to take Tcl further. 

----
[RS]: I like the first style, for reading accesses, much better:
 set value $dic($key)           ;# 1) not possible now
 set value [dict get $dic $key] ;# 2) planned in 8.5
But in the other direction, we get an asymmetry when setting a value:
 set dic($key) $value           ;# 3) creates dic as an array, if it doesn't exist
 puts $dic                      ;# 4) error if array, success if dict
----
[MS] is not clear as to the expected behaviour of [upvar] and [trace]. Currently they are able to operate on individual elements of arrays (which are themselves variables) but not dicts (whose elements are values).

Another issue is how the proposed changes apply to nested dicts - would the $ syntax require some expansion?

Semantically, dicts are much closer to lists than to arrays. A TIP to extend the $notation to lists was rejected some time ago (just info, not arguing for or against anything).
----

[MS] also notes that this proposal poses some deeper difficulties. Consider
 set A "0 1 2 3"
 set B [list 0 1 2 3]
 set C [dict create 0 1 2 3]
Now: $A, $B and $C are equal, as they are represented by the same string. The question is: should $ interpret the first two also as dicts, or consider them as different types? 

If $B is interpreted as a dict, we would get things like
 set B [list 0 1 2 3]
resulting in $B(0) (value 1) being different from [[lindex $B 0]] (value 0),
which may or may not be what the user is expecting.

Another problem: strings that can be converted toa list with an even number of elements can be interpreted as dicts, if the number is odd they can't. What should Tcl then do with
 set str1 "hi call me miguel"
 set str2 "hi please call me miguel"
 puts $str1(hi)
 puts $str2(hi)
 
OTOH, introducing types in Tcl semantics (violating '[everything is a string]') is most probably a no-no.

'''CN''': actually, your C doesn't have a well defined string representation until you use it, so it will only equal $A and $B half of the time; I actually find this amusing: just checking for equality can presumably effect the execution order of a later "foreach x $C {...}"! (And now, approx. three minutes later, I'm no longer so sure that I want to keep up this claim about the changing execution order: presumably this could only happen if there were two dict functions that had different preferences about the access order... and presumably this condition is currently void. Oops.)    

[DKF]: I think there'd need to be a command to declare that a variable can be used as an array and what interpretation to put on the keys (dict keys, list indices, etc.)  Having a command to set something clever in Tcl's guts wouldn't violate anyone's ground semantics...

----