Re: merging variables and arrays ... conflicting with cloverfield?

On May 30, 1:45 pm, Andreas Leitgeb <a...@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
fredericbon...@xxxxxxx <fredericbon...@xxxxxxx> wrote:
merging arrays with dicts. E.g.:

There is a fundamental difference between values and containers.
Scalar variables and arrays are containers, whereas dicts are
just values.

Syntactically mixing arrays and dicts is a worse idea, imho,
than range-syntax for lists. lists don't have a container-
pendant, so it would cause less of a confusion.

(Note: let's forget about the (mostly defunct) range syntax for now,
will we? ;-)

Unless you target Tcl9: merging arrays and regular values (dicts in
Tcl8.5) has been a long term goal for some time now. That was my
point, that we shouldn't prevent this potential improvement in the
future.

Cloverfield is meant to be a potential Tcl9, but is far from being the
only one. See for example the wiki pages regarding Tcl9. The idea of
merging arrays with dicts is shared by many people.

If dicts also used array-syntax this would create much more
confusion, and you haven't yet answered (on tcl-core) how to
deal with the semantical conflict between using "a b" as a
key in an array (where it is seen as one key) and for dicts,
where you claimed it would mean two separate nested keys.

Done!

However why not add default values to dict variables? (it slightly
violates EIAS but anyway).

It wouldn't violate EIAS at all!

It would, if we kept the current serialization format that uses even-
sized lists. In this case this would need some out-of-band
communication system (read: a specific command that accesses the
hidden value), which is un-EIAS. But if we decide, as you propose
below, to use the last element of an odd-sized list as the default
value, then everything is fine. However you have to adapt [array get]/
[array set] accordingly, as dicts are designed around the same
interface (Tcl8.5 [array get] even returns a dict obj).

Anyway, I still think it's a bizarre idea that violates the principle
of least astonishment.

One could add an optional default-value as last element to
the "list" rep of the dict, looking like an odd-sized list then,
and treat that unpaired element as the default-value if present.

It's a matter of the dict-accessing commands, to do the check
for a default on key-miss, and to provide a dict-api to create
new dict-values with changed default values from existing dict-
values, just like there are api's to create dicts with some
element replaced from an original. Dicts are in value-land.

I didn't yet intend to do it, but if it was done, then
array set a {1 2 3} would define a(1) as 2 and a as 3.
That way, the information of such a combo var could
be retrieved completely in one step, namely [array get a].
.

Relevant Pages

  • Re: TIP #185: Null Handling
    ... specify the names of the columns, in a Tcl *list* that preserves order, ... and then iterate over the list pulling out the array values in order. ... I could pass around a list of lists pretty easily, ... dicts, that might be a workable solution. ...
    (comp.lang.tcl)
  • Re: What does Tcl lack?
    ... > traces on array elements, ... > If some Tk problem is solved very well with traces ... If the only good reason is to free up the syntax sugar for dicts, ...
    (comp.lang.tcl)
  • Re: Reference or Value?
    ... Integers are obviously passed by value, lists and dicts by reference. ... It's just that lists and dicts are containers whose contents you can ...
    (comp.lang.python)
  • Re: multidimension variables
    ... > lists is more efficient than using array indices like $i,$j. ... > sticky bit is setting up the list of lists to begin with, ... efficient than dicts of dicts. ...
    (comp.lang.tcl)
  • Re: array of lists
    ... If you have 8.5 then this is a job for dicts. ... array of dicts. ... But I'm a bit concerned by the per-dict memory overhead. ... I'd suggest using just one single array with richer keys. ...
    (comp.lang.tcl)