From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7575 invoked from network); 30 Jul 1997 15:58:46 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 30 Jul 1997 15:58:46 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.8.5/8.8.5) id LAA06229; Wed, 30 Jul 1997 11:53:55 -0400 (EDT) Resent-Date: Wed, 30 Jul 1997 11:53:55 -0400 (EDT) Date: Wed, 30 Jul 1997 19:54:01 +0400 (MSD) From: Andrej Borsenkow X-Sender: bor@itsrm1 Reply-To: borsenkow.msk@sni.de To: Andrew Main cc: Zoltan Hidvegi , schaefer@brasslantern.com, zsh-workers@math.gatech.edu Subject: Re: RC_EXPAND_PARAM bug In-Reply-To: <199707300818.JAA26068@taos.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"uGINJ3.0.DX1.IEstp"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3398 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Wed, 30 Jul 1997, Andrew Main wrote: > Zoltan Hidvegi wrote: > >What would be the preferred evaluation of ${^a}1${^^x}? > > Who cares? Anyone mixing plan9 and non-plan9 array expansions is asking > for trouble. Perhaps the documentation should warn against it. > After looking at rc, I agree. Actually, the implementation in ZSH is so different, that the name RC_EXPAND_PARAM is just misleading. In rc, there are two legal cases: 1. concatenation of scalar (or rather list of length 1, as rc doesn't have scalars at all); it corresponds to RC_EXPAND_PARAM in ZSH: ; a=(a) ; x=(x y) ; echo $a$x ax ay 2. concatenation of two lists of _equal_ size; it is _pairwise_ and not cartesian product as in ZSH: ; a=(a b) ; x=(x y) ; echo $a$x ax by Anything else is error: ; a=(a b) ; x=(x y z) ; echo $a$x bad concatenation As far as ZSH goes, I am not shure, if any reasonable way to mix arrays with and without RC_EXPAND_PARAM in one line (word to be shure) exists. Any way you select will give you very strange results sometimes. Probably, it is enough, if RC_EXPAND_PARAM works with scalars, and FAQ should mention, that anything else should better be avoided. The important thing is to document how selected method really works and most intuitive to me looks like disallow such mix at all ;) ------------------------------------------------------------------------- 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 -------------------------------------------------------------------------