Re: Dict sharing vs. duplication


On Dec 22, 5:40 am, Fredderic <my-name-h...@xxxxxxxxxx> wrote:
On Fri, 21 Dec 2007 11:04:36 -0300,

miguel <mso...@xxxxxxxxxxxx> wrote:
schl...@xxxxxxxxxxxxxxxx wrote:
Larry W. Virden wrote:
Weird - I thought the whole reason for dict was so that we had a
data structure that was treated as a first class object - instead,
we have Just Another Second Class Structure (JASCS)?
Its a first class object. But the Tcl value semantics and the no
duplication do not play together well. A dict is no better than a
list in that respect.
What some people would like is reference semantics.
upvar?

is slow and limited.

I have a situation I think I'm mentioned before on here, where I have
backend data manipulation functions, middle generic algorithms (some of
which in turn use others within that same layer), and then task-specific
front-end functions that combine the available backends and middle
algorithms in ways that are meaningful to their specific task.

The problem comes when a backend wants to be passed a reference, and
the variable it's interested in happens to be proc-local. Now, you
can't just pass a name, because it's not globally accessible, and by the
time you get to the back-end procs, you don't know how many levels back
it is. Which means that you have to pass TWO pieces of information.
The name of the variable, and the level at which it is known to exist.

True references would remove the need for such special handling
completely. You'd just pass a reference to the variable, which would
be valid as long as the variable itself was, and local to whatever
proc it was passed into.

But here comes one of my three gripes with [dict]s. What if the value
you want to pass by reference, is not only proc-local, but also within a
[dict]? [upvar] can handle arrays just fine. But it lacks the means to
reach into a [dict], let alone a nested [dict].

If TCL data structures had the capacity to export references, again,
this all would be resolved. You could simply use [dict reference] (for
example) to obtain a reference to a value at an arbitrary depth, and
then pass that reference on as needed.

I have implemented a reference type mechanism by creating a temporary
global shadow variable, and using traces to bind them together. The
mechanism can quite readily handle just about anything, and as it uses
lazy updating, it actually has reasonably decent performance. But it
is messy, complicated, and shouldn't be needed. Most importantly, it
won't handle new types of data added by extensions.

On a side-note, my other two gripes with [dict]s, are they don't
support traces, and there's no get-and-report or get-with-default
methods (both of which I use extensively from my home-grown pre-dict
keyed list implementation). A forth minor gripe is that the string
representation of a [dict] (and an [array], which I suppose it's
intended to be compatible with) is particularly useless.

Have you ever tried namespaces? It is a very powerful concept, and can
allow you to avoid upvar in most situations. I say most because there
is nothing inconvenient with using upvar if you don't have to pass
around a level indicator.

I did a search through a recent large body of code I wrote, heavily
focused on this concept. Upvar is used only a handful of times, and
never with a level reference. In fact, all of the uses are helper
functions, not the main line of programming:

http://junom.com/gitweb/gitweb.perl?p=twsdl.git&a=search&h=HEAD&st=grep&s=upvar

As an example, I use a namespace name as a pure reference to provide
total isolation between three different components: protocol, data/xml
container and invoked procedure. And the reason is exactly as you
state it: it is not good design to think in terms of levels if there
is not much of a real relationship between them, thus using upvar is a
kludge more than a programming style. (I like to think of namespaces
as named stacks.)

Here is a series of examples using namespaces and upvar together to
use an nvlist:

http://junom.com/gitweb/gitweb.perl?p=twsdl.git;a=blob;f=packages/tws/tcl/nvlist-init.tcl

The idea is simpler than a dict and very space efficient. Obviously
the general concept of a name-value list is like a serialized array,
however the examples above show how a few simple API can introduce the
concepts of both enumeration and records. The last example compares
the nvlist with the example given for [dict] in the Tcl manpages. The
space efficiency is worth noting: you create two nvlists, one for
values and one for the names, so names are only included once and can
be used to get the index of the value list.

But note: this two nvlist solution is for space efficiency and is not
a self-describing structure like a dict.
.

Relevant Pages

  • Re: Dict sharing vs. duplication
    ... That is what [upvar] is for. ... You could simply use [dict ... reference] to obtain a reference to a value at an ... or to modify data via unrelated procedures. ...
    (comp.lang.tcl)
  • Re: Dict sharing vs. duplication
    ... passing it to [dict filter], but that's normal and not duplication. ... the idea is that a reference type would somehow avoid ... what level to use for upvar. ... upvar $dictName localDict ...
    (comp.lang.tcl)
  • Re: open() behavior under heavy disk load
    ... effects which may be created because of race conditions ... recently occured when a refence-counted data structure was supposed to ... represented while there was still an active transmission for this ... reference to the first data structure, too, because replies could come ...
    (comp.os.linux.development.system)
  • Re: using reflection to discover a nested structure
    ... working with an instance of the object (i.e. my data structure). ... I do not want to have to reference each element of each structure ... need to find out how to reference each element of a nested array through ... FieldInfo field = t.GetField; ...
    (microsoft.public.dotnet.general)
  • Re: Dict sharing vs. duplication
    ... data structure that was treated as a first class object - instead, ... Its a first class object. ... What some people would like is reference semantics. ... But here comes one of my three gripes with s. ...
    (comp.lang.tcl)