set -A and stat -A vs. typeset -A and stat -H

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

Phil P. has expressed interest in going back to `typeset -H assoc' rather
than the ksh-inspired `typeset -A assoc' presently in use.  I objected on
the grounds that (H)ash, as e.g. used in the `stat -H' documentation, is
the wrong way to refer to associative arrays; it implies too much about the
implementation.

It occurred to me that a compromise would use the more accurate term "map"
to refer to associative arrays, and change to `typeset -M' and `stat -M'
(with special-case code for `typeset -A' in ksh emulation mode).  When
investigating this further, I find the following problems:

`set -M' already means `setopt single_line_zle' (of all things); in fact,
the only letters NOT already taken for `set' are b, c, d, q, and z, so we
might as well give up on congruence between `typeset' and `set'.  (BTW,
for those who've forgotten, `set -H' means `setopt rm_star_silent'.)

${(M)...} means "include (M)atching portion" when combined with certain
other parameter expansion operations, so it's out for what's now ${(AA)...}.

In other contexts, -M introduces things like zle keymap names, so there
is still a potential for confusion (though manipulating keymaps through
associative arrays is an interesting idea).

I send this along mainly to illustrate the sort of problems we face when
trying to avoid inconsistencies in command interfaces.  Certainly this is
to be avoided when possible (which is why I asked earlier for a summary
of the state of programmable completion), and certainly the time to do it
is while we have a development version (I have far less compunction about
breaking compatibility with 3.1.2 than I do with 3.0.5); but unless it's
really a glaring conflict it's usually best to make the right decision for
each command individually.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com