|
|
fredericbonnet@xxxxxxx <fredericbonnet@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.
Dicts are "portable baggage", just like suitcases.
Suitcases can be used to transport stuff, or even to
list/retrieve items from it, and stuff others in, but,
what is packed in there is just not as conveniently
accessible as when it's in a drawer of the cupboard.
Cloverfield is (to my initial surprise) mostly conforming to
this concept: two lists of equal string-rep are still identical,
and however you fiddle around with references, either you
effectively create a new list which is then just different
from its previous variant, or you change the target of an
external ref, which means that all lists with same string-rep
will reflect the change in the same way and thus remain
indistinguishable among each other.
if I have:
set a {1 2 3}
set b {1 2 3}
$a and $b are indistinguishable.
if I then do:
set c $&b{2}
I actually changed the value stored in b, from {1 2 3} to
{1 2 {ref xyz}3}, so it is no longer the same as $a
The semantics of cloverfield's indexing/range-operators are
unique to list.
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.
> But actually it's more about merging arrays and scalar variables, so
> that arrays have a scalar value that serves as a default value for
> unknown keys.
yes, indeed.
> While not without merit, I think that it's a bad idea
> because it would prevent any future merger of arrays and dicts, which
> would make more sense IMHO.
Let's agree to disagree here on the merit of merging dicts with arrays,
will we? :-)
> However why not add default values to dict variables? (it slightly
> violates EIAS but anyway).
It wouldn't violate EIAS at all!
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].
|
|