RE: PATCH: param stuff and was: PATCH: 3.1.5-pws-12: _brace_parameter

["Andrej Borsenkow" <borsenkow.msk@xxxxxx>]

>
> This ounds good, but can't be done easily (I think). The problem is
> that in the case of a `${${...}...}' the code currently just takes the
> inner `${...}' and calls `prefork()' on it (which does most of the
> expansions). The result is a list of strings and no other
> information. So here, the result of an one-element array and an scalar
> is indistinguishable. This means that we have to say in the *outer*
> `${...}' if we want the result of the inner one to be treated as an array.
>

Can I formulate it as: every substitution is done as if it were the
top-level one?

>
> The problem is that this is even more uncompatible with previous
> version than what we have now.
>

The problem ZSH always had (and have) is very poor documentation. I think,
the (partial) reason for it is, nobody actually knows, how it behaves. New
features are added on ad-hoc basis, without clear picture, how the whole
works.

Currently there are several ZSH wizards that either know all ins and outs by
heart or know source code. It is virtually impossible for ordinary user to
use the power ZSH provides, because the only way to do it is by trial and
error. You never can tell, what is a result of a (mildly complicated)
expression simply by looking at it.

Can anybody explain (in the manual) how ZSH substitution really works?
Returning to my example:

bor@itsrm2:~%> foo=(bar baz)
bor@itsrm2:~%> print "${(@)${foo}[1]}"
bar baz
bor@itsrm2:~%> print "${${(@)foo}[1]}"
b

Could anybody explain, why? We take the value of foo, that is (bar baz). The
whole is quoted, so it is converted to scalar. Then, all of a sudden, this
scalar is converted back to array! Why?  What about second? On the top
level, (@) prevents array->scalar converting:

bor@itsrm2:~%> print -l "${(@)foo}"
bar
baz

But why it does not happen with inner ${(@)foo} in the above case? How can I
take array slice in double quotes?

That is only one example of inconsistency. The answer "it is implemented
this way" is very weak argument. What I'd like to hear - *why* is it
implemented this way.

We already had a long shot at RC_EXPAND_PARAM. Yes, it was incompatible with
previous version - but it made RC_EXPAND_PARAM finally useful - and
*predictable*. What I'd like to see in parameter expansion - it is
predictability.

cheers

/andrej