This page written by [DKF]
----

What is good about [Tcl]'s arrays?  Their compact syntax for common operations.

What is not so good about [Tcl]'s arrays?  You have to use a hash-table for the mapping from keys to values.

Would would make things extra cool?  If we could take arrays and put a new back-end on them based on [list]s, [dict]ionaries, or even something more exotic.  There have been attempts to do this in the past ([BLT]'s vectors spring to mind here)

Why do this to arrays instead of putting magic conversion on values?  We'd have a proper named location to store the metadata describing how the array is implemented.

What is going to be hard?  Well, [trace]s are definitely tricky, as is [upvar] and friends, as they both (currently) require that your mapping mechanism hands out references to a '''Var''' structure, and that's not something that you can really map nicely onto a [Tcl_Obj] as it is an updatable structure.
----
'''What Operations are Needed?'''

   get:   Retrieve a value from the mapping given a key.  This operation should succeed if the key was one returned by the '''list keys''' operation below; behaviour for other keys is undefined in general.
   set:   Update or insert a value into the mapping given a key
   unset:   Update the mapping so as to remove an element
   list keys:   Get the list of keys that map to data values.  Note that an array might be permitted to support other keys with "magic" names, but this operation should only list the keys that map in a straight-forward fashion.
   serialize:   Convert entire array to a string (preferably in the order listed by the '''list keys''' operation.)
   deserialize:   Convert string to array

[[...]]

----
[RS] Don't [array]s (and [dict]s) represent a string -> value mapping, while vectors (and [list]s) do (0<=int<maxint) -> value?

[DKF]: So what if vectors/lists have a restricted language of keys?  :^)

''13may04 [jcw] - Cool!  The serialize/deserialize operations are "slightly less primitive operations" IMO, in that they can be implemented with the first four.  The get/set/unset/list combo is the core.  They offer all sorts of interesting new options, similar to Perl's "tie".  My first goal would probably be to map this to hashed Metakit views, i.e. persistent memory-mapped arrays.  Gdbm is another obvious candidate.  More advanced uses may need some more machinery, but I think most of that can be done in Tcl.''

I'd like to describe an idea which unifies keyed access (arrays), indexed access (lists), scalars, and more - but let me just point to [http://www.equi4.com/39] and [http://www.equi4.com/179] for now.

----
[RHS] ''08June2004'' I've been thinking a lot about arrays and how they aren't "first class citizens" when it comes to being data objects. Other than the fact that it would require a lot of work to make the change, what are the reasons for not converting arrays to be TclObjects that could be shimmered to/from other types of TclObjects? By way of an example, I think it would be very handy to be able to do:
 set bob {a 1 b 2}
 puts "bob(a) = $bob(a) -> should be 1"
 puts "bob = $bob -> should be {a 1 b 2}"
 set bob(c) 3
 puts "bob = $bob -> should be {a 1 b 2 c 3} or {b 2 a 1 c 3} or {c 3 b 2 a 1} or etc"

My thought is that, by converting tcl arrays to TclObjects and allowing them to shimmer to/from other types, that we would now be able to return arrays from procs, pass them in by value, etc.

Other than the obviously huge amount of work the conversion would require, what are the major problems with this approach?

''Traces perhaps?'' [RS]: As soon as we have [dict]s, these can take over all the pure-value/first-class usages, and [array]s will be used less, I expect.

[NEM] There is a major problem with this approach (overloading array syntax). Let's rearrange the items in your example:

 set bob {1 a 2 b}
 puts "bob(2) = $bob(2) -> should be... err 'b' if it's a dict/array, or 'a' if it's a list..."

As you can see, this introduces an inheritant ambiguity. The return value depends on the current underlying Tcl_ObjType of the Tcl_Obj (value) - thus exposing a previously hidden implementation detail, and radically changing Tcl's script-level semantics. I wrote some notes on a related subject at [http://mod3.net/~nem/tcl/interfaces.xml] a while back. A possible way out is to introduce type-tagging at the script-level (so that the current type becomes a part of the string rep) where you want this sort of polymorphism. See [TOOT] for my experiments in that direction (no use of array syntax, but I think the idea could carry across, with some work).

[DKF]: My idea is that the [array] command will get a new subcommand which allows you to declare a new array with an alternative implementation inside it.  This might work like this:
  array declare bob -type list  ;# Support more options (e.g. database username/password)
  array set bob {a b c d}       ;# Set up the array contents
  puts "bob(2) = $bob(2)"       ;# which is the value "c" if it is a list, of course.

----
[[ [Category Internals] | [Category Discussion] ]]