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

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

[Bart Schaefer]

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

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

[Phil Pennock]

Typing away merrily, Bart Schaefer produced the immortal words:
> 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.

You might with to check the documentation for the stat module, which
seems up to date.  I've just got 3.1.5-pws5 here and opened it to
verify my memory.

`stat -A' was already taken.  For assigning to an Array.  This is why I
looked around for another value, and is probably the point at which I
started getting really annoyed about the option values.

Hrm... just went searching for this.  From fortune(6):
        Stop!  Whoever crosseth the bridge of Death, must answer first
these questions three, ere the other side he see!

        "What is your name?"
        "Sir Brian of Bell."
        "What is your quest?"
        "I seek the Holy Grail."
        "What are four lowercase letters that are not legal flag arguments
to the Berkeley UNIX version of `ls'?"
        "I, er.... AIIIEEEEEE!"

HAND (and no, the first two letters of that are just coincidence).
-- 
--> Phil Pennock ; GAT d- s+:+ a23 C++(++++) UL++++/I+++/S+++/B++/H+$ P++@$
L+++ E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++
DI+ D+ G+ e+ h* r y?

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

[Bart Schaefer]

On Jan 28,  1:23pm, Phil Pennock wrote:
} Subject: Re: set -A and stat -A vs. typeset -A and stat -H
}
} You might with to check the documentation for the stat module, which
} seems up to date.

Yes, I did.  The actual string "(H)ash" isn't used any more, but the
name of the argument for -H is still "hash".

} `stat -A' was already taken.  For assigning to an Array.

Yes, and is so because of `set -A', I imagine (hence the Subject).  My
point is not that you should have chosen -A for `stat', but that there
really isn't *any* option letter that can be the same for all of `set',
`typeset' and any third command you might name.

}         "What are four lowercase letters that are not legal flag arguments
} to the Berkeley UNIX version of `ls'?"
} 
} HAND (and no, the first two letters of that are just coincidence).

Um, HAND are not lowercase letters ... and BSD `ls' does use -A. ;->
(My answer would be e j v y, but I had to think about it for too long.)

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

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

[Bruce Stephens]

"Bart Schaefer" <schaefer@brasslantern.com> writes:

> On Jan 28,  1:23pm, Phil Pennock wrote:

> }         "What are four lowercase letters that are not legal flag arguments
> } to the Berkeley UNIX version of `ls'?"
> } 
> } HAND (and no, the first two letters of that are just coincidence).
> 
> Um, HAND are not lowercase letters ... and BSD `ls' does use -A. ;->
> (My answer would be e j v y, but I had to think about it for too
> long.)

The ls I've got doesn't use h, but it certainly uses a, n and d.  Are
there really versions of ls which don't support a or d?  I use those
options all the time.

Anyway, that shows there's room for expansion, should zls need more
options.

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

[Phil Pennock]

Typing away merrily, Bart Schaefer produced the immortal words:
> On Jan 28,  1:23pm, Phil Pennock wrote:
> } `stat -A' was already taken.  For assigning to an Array.
> 
> Yes, and is so because of `set -A', I imagine (hence the Subject).  My

Helps to read things properly.  Oops.

> point is not that you should have chosen -A for `stat', but that there
> really isn't *any* option letter that can be the same for all of `set',
> `typeset' and any third command you might name.

I hope that you mean, "you should have been able to choose -A for
`stat'", since it was already taken by whoever implemented that.  I
didn't change it, for compatibility.  But hey, stat's new to 3.1.5
(afaicr) so whatever.

Generally, I have no objections whatsoever to changing the option.  I
was just gratified to see someone modify the examples to make use of my
addition.  A nice warm fuzzy feeling inside... :^)

> }         "What are four lowercase letters that are not legal flag arguments
> } to the Berkeley UNIX version of `ls'?"
> } 
> } HAND (and no, the first two letters of that are just coincidence).
> 
> Um, HAND are not lowercase letters ... and BSD `ls' does use -A. ;->
> (My answer would be e j v y, but I had to think about it for too long.)

I was actually thinking of 'HA' in relation to the stat options.

Erm, Bart, is that the first time that you've used a smiley on the
zsh-workers list?  :^)  *ducks*

Anyway, back on topic.  Given all this overloading in typeset and set,
how feasible is it to do a split-out, similar to the completion stuff
recently?  Ie, carefully examine the functionality requirements, add (I
suspect) three new builtins, organise the options consistenly for those.
Make the set and typeset compatibility interfaces with a couple of other
bits left ('set'ting the argv stuff), and then remove any options that
weren't there in 3.0.x.

Yes, it pollutes the namespace some more.  But how viable is it to
continue the way things are at present, squeezing more and more into a
limited space with consistency conflicts?

(PS: I start shifts soon, and should be able to hack zsh a bit more when
I'm on nights - fear)
-- 
--> Phil Pennock ; GAT d- s+:+ a23 C++(++++) UL++++/I+++/S+++/B++/H+$ P++@$
L+++ E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++
DI+ D+ G+ e+ h* r y?

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

[Bart Schaefer]

On Jan 28,  5:50pm, Phil Pennock wrote:
} Subject: Re: set -A and stat -A vs. typeset -A and stat -H
}
} Generally, I have no objections whatsoever to changing [stat -H].  I
} was just gratified to see someone modify the examples to make use of my
} addition.  A nice warm fuzzy feeling inside... :^)

Here's an idea ... simply use `stat -A' for both, and have stat examine
the type of the parameter to which it's assigning to choose the behavior.
For that to work cleanly, though, stat would have to refuse to create a
parameter that didn't already exist.

`set -A' could do the same, for that matter, though it's been around a
lot longer so it probably couldn't get away with refusing to create new
parameters.

} Erm, Bart, is that the first time that you've used a smiley on the
} zsh-workers list?  :^)  *ducks*

No, it isn't the first time, but a while back someone I worked with used
smileys so often that they became meaningless/annoying to everyone else,
and consequently I pretty much stopped using them unless my meaning might
be completely misconstrued without one.

} Anyway, back on topic.  Given all this overloading in typeset and set,
} how feasible is it to do a split-out, similar to the completion stuff
} recently?

One can do almost anything with modules, except modify the lexer/parser.

} Ie, carefully examine the functionality requirements, add (I
} suspect) three new builtins, organise the options consistenly for those.

What three are you thinking of?

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