Re: Two questions

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 27, 10:59am, Phil Pennock wrote:
} Subject: Re: Two questions
}
} Typing away merrily, Bart Schaefer produced the immortal words:
} > On Jan 26,  6:32pm, Phil Pennock wrote:
} > } Recently zsh has changed a number of things to be more compatible with
} > } ksh.  And some things, such as the associative arrray stuff, has
} > } followed what seem to be dubious criteria in order to be compatible.
} > 
} > Could you please describe which "dubious criteria" you mean?  Other than
} > the fact that we now have conflicting meanings of the -A option for some
} > nominally related commands, I thought we were doing pretty well with the
} > associative array stuff.
} 
} That was the main one I was thinking of.  And also the hassles with
} syntax for subscripting and the like.  Bart, you were quite vocal at the
} time.

I just read back through the whole thread.  The place where I thought ksh
was "daft" was in the nameref syntax, ${!ref}, and its extension to the
associative array syntax, ${!assoc[@]}.  And what those of you on the zsh
mailing list didn't see was that Tim and I carried on the nameref thread
privately, and it turns out ksh isn't quite as daft as I thought:  It has
completely separate namespaces for namerefs and parameters, though it is
a bit strange in that you seemingly can't ever un-set a nameref.

Anyway, zsh 3.1.5-pws-[45] doesn't use the ${!assoc[@]} syntax except when
"setopt ksharrays" which seems to me exactly the sort of thing that both
of us have been advocating.

} [...] every time something breaks or something goes, just to
} be like ksh (eg, PWD (& auto-resize?)), zsh loses a part of that which
} makes it unique.

I'm not terribly concerned about bits that make zsh unique, but I'm in
complete agreement about breaking things.  There ought to be *extremely*
good reasons for introducing any change that breaks my dotfiles or makes
me interact with zsh differently.  There have been several such changes
over the past few years that didn't meet my criteria for "*extremely*
good reason," but little of that applies to the addition of entirely new
features borrowed from elsewhere.

} Every time that we say, "Yes, you could do that, but we changed it for
} compatibility with ksh, so now you have to use this workaround" we're
} detracting from zsh.

I agree again, but please keep in mind that 3.1.x is the development
version of zsh.  In the case of, for example, the PWD/OLDPWD changes,
I'm sure the effect on autonamedirs was simply an oversight.  That's
one of the problems with zsh having so many options and doodads, you
can't tell what a seemingly innocuous change is going to impinge upon.
The important thing is not that PWD et al. be "special" variables, but
that we get the problem resolved before 3.1.x becomes the "official"
3.2.0 release.

The auto-resize stuff, BTW, got changed in response to a different bug
report, which IIRC had something to do with (a) windows resizing when
a job was in the foreground so zsh wasn't listening, and (b) improper
settings of the window size in termcap entries, which zsh believed in
preference to believing the LINES and COLUMNS variables.  It happens
that the fix may have gone too far in the other direction, and then in
turn that 3.0.5 and 3.1.5 didn't stay in sync on the patches.  The
latter is a problem with having separate "production" and "development"
versions, particularly when they've diverged as far as 3.0/3.1 have.

} Isn't it more important to make zsh better and do it _right_, with as
} little unnecessary confusion as possible, rather than just "it does
} that too, and is just as bad"?
} 
} -a vs -A vs -H vs whatever is just a case in point.  There needs to be a
} clear unambiguous meaning for each, instead of "'-A' means associative
} here, but the option was already taken there, so use '-H' instead".

There have been cases in the past where an option (like -m) was co-opted
(sorry) to have the same meaning (glob pattern follows) across a range of
commands, even if it already had some other meaning for some of them.

} > [...] if you're adding something that another Bourne-like shell has
} > already implemented, do it the same way as that other shell UNLESS that
} > already conflicts with an established zsh usage.
} 
} And when the other shell doesn't directly conflict, but leads to
} confusion in other areas which aren't in the other shell?

Depends on how bad the confusion is, really.  Clarity certainly should be
among the criteria.

} I'm not a key developer, feel free to tell me to get lost or whatever.

We try not to do that.  Everybody's opinion counts for something.

} But IMNSHO some aspects of the ksh associative-array syntax suck.
} Mightily.

Can you list them?  Is it just that `set -A' and `typeset -A' don't have
congruent meanings?  What else?  (When you say "associative array syntax"
I think of $foo[bar] and relations, which really is already as close to
standard zsh array-variable syntax as it can reasonably get.)

On Jan 27, 11:28am, Bruce Stephens wrote:
} Subject: Re: Two questions
}
} If bash has all the features that I currently use in zsh (mostly
} completion and globbing), then I'll be happy to use bash.

I think that was pretty much Phil's point -- he doesn't want you to be
as happy to use bash as you are to use zsh.  Zsh should have the edge
on happiness.

On Jan 27,  1:46pm, Peter Stephenson wrote:
} Subject: Re: Two questions
}
} I rely on Bart for the look and feel angle.

Well, thanks.  (Speaking of happiness, *I'd* certainly be a lot happier
if all the maintainers had done that, but ....)

On Jan 27,  2:11pm, Phil Pennock wrote:
} Subject: Re: Two questions
}
} Personally, I think that Bart was correct in his judgement and that ksh
} is daft in this respect.  Bart, any chance of restoring 'typeset -H' and
} making 'typeset -A' (was it?) a compatibility way in, for ksh
} compatibility?

It could be special-cased.  The way `typeset' works, the position of the
option letter in a string determines the bit that gets turned on in a
flag word, so it requires extra code to have two letters that mean the
same flag.

It'd also be possible (maybe even easier) to add a declarator like the
`integer' and `local' commands, distinguished on the command name.

} Generally, the array/Associative array thing could do with becoming an
} array/Hash thing.  And sorting out what needs to be in 'set' and what in
} 'typeset'.

Let me say that I was actually happy about changing `typeset -H' to `-A'
because I don't like referring to associative arrays as "hashes".  They
happen to be implemented that way, but there's no reason they have to be,
and the term "hash" (and the command name `hash') is already taken in zsh
to refer to various command and filesystem mapping-related things.

I personally dislike the choice of -H for the option you added to `stat',
for exactly this reason.  But I don't use the stat module, so I didn't
bother to complain.

} This is a user-interface thing as much as anything else, so
} any one person declaring correctness wouldn't be as good as discussion
} and consensus (hence these posts).

Yes.

} PS: did anything ever come of adding namerefs?

No, nothing has come of that.  It's not particularly necessary in zsh,
because you can do this:

zsh% ref='$param'
zsh% param='This is the value of param'
zsh% echo ${(e)ref}
This is the value of param

The only reasons for adding namerefs would be ksh compatibility and to get
the separate namespace.

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