|
|
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].
|
|