Re: RC_EXPAND_PARAM bug

[Andrej Borsenkow <borsenkow.msk@sni.de>]

On Wed, 30 Jul 1997, Bart Schaefer wrote:

> 
> I think the beta16-and-earlier cartesian product was reasonable and gave
> consistent results.  However, I encourage a warning in the doc that the
> results are not the same as for rc and that mixing ${^x} and ${^^x} in
> the same word may not behave in the way one expects. 
> 

There is probably one more alternative, but let me first explain how I
understand the problem.

/bin/sh (and POSIX sh) rules are based on textual substitution. They are
very simple and consist of well defined steps:
  1. break line into sequence of substitutions
  2. evaluate each of them
  3. concatenate results
  4. break result in words with field splitting

ZSH coompicates it by adding arrays. They can still fit in above scheme,
if we define what $array means. ZSH defines it as "$array[@]" which is
quite acceptable (I don't speak about implementation; I understand, arrays
are actually implemented as lists internally).

RC_EXAPND_PRAMS is based on absolutely different assumption. Original
implementation (rc) operates on _lists_, and is using _binary operator_
and not plain substitution/concatenation. The '$a$b' in rc is just
shorthand for '$a^$b' where `^' is binary opereator (wether pairwise or
cartesian product doesn't actually matters). rc just cannot have our
problems, because it is driven by usual operator precednce rules.

Both implemetations (pre-beta16 and current) actually do the following:

  - break word into ^- and non-^-parts
  - do substitutions on non-^-parts (and on nested substitions in
    ^-parts) based on traditional (textual) rules
  - convert results into lists (implicit field-splitting)
  - combine the lists

They differ just in how lists are combined:

   pre-beta16 treats `^' as ternary operator:
     xx$^ayy -> xx^$a^yy (in rc notation)
   current treats `^' as binary operator with right precedence:
     xx$^ayy -> xx($a^y)

Both is acceptable as long as it is documented ;)

Correct me, if I am wrong.

Now, if the above rules are explicitly stated in ZSH docs it is
enough. It will enable users to understand what's really going on, which
is very hard to do now ;-} I suggest, that zshexpn(1) explicitly states
this additional step and how it works (FAQ could then give some examples).

The same holds true for brace expansion as well (which is currently done
differently from RC_EXPNAD_PARAM).

Oh, I almost forgot my proposal ...

  - get rid of ^ as subst modifier
  - use explicit operator notation; something like
     ${prefix^suffix}, where prefix and suffix are expanded, converted
     to lists and combined. The result is then stuffed in replaced 
     string in usual manner (as if it were array - which by the way it is
     ;)
    We could include operator precedence so that
     ${xxx^yyy^zzz} could be used.

I am not shure if current grammar permits use of `^' in this case, but I
still like the idea ...

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------