From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-7537-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 27055 invoked from network); 30 Aug 1999 09:19:49 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 30 Aug 1999 09:19:49 -0000
Received: (qmail 19606 invoked by alias); 30 Aug 1999 09:19:40 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 7537
Received: (qmail 19599 invoked from network); 30 Aug 1999 09:19:38 -0000
Date: Mon, 30 Aug 1999 11:19:37 +0200 (MET DST)
Message-Id: <199908300919.LAA20587@beta.informatik.hu-berlin.de>
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
In-reply-to: "Bart Schaefer"'s message of Fri, 27 Aug 1999 17:24:27 +0000
Subject: Re: Nested associations (was Re: PATCH: completion functions)


Bart Schaefer wrote:

> On Aug 26, 11:28am, Sven Wischnowsky wrote:
> } Subject: PATCH: completion functions
> }
> } [If] we were able to put arrays and associations into associations, we
> } could have command-specific caches. Internally, this probably wouldn't
> } be too hard to implement, I think, but if I remember correctly, Bart
> } was against it and explicitly disallowed this. Maybe if we just tell
> } the users that associative arrays can act as name-spaces? (In other
> } words: Bart, what was the reason that you was against it? Or weren't
> } you against it and my memory is failing?)
> 
> I wasn't against it; in fact I particularly arranged the storage for
> associative arrays to allow for it to be added in the future.  There are
> a number of reasons why I didn't do more with it:
> 
> I thought it would be better to have it thoroughly tested and working
> one level deep before allowing nesting.
> 
> I think we need better assignment syntax before allowing nesting; how
> do you copy one nested AA to another?
> 
> Similarly, I can't decide how expansion should behave.  What happens when
> you refer to the entire tree structure with $outermostname ?  What about
> ${(kv)outermostname}; do the flags propagate to the nested arrays?  Why?
> When you ask for $outermostname[(r)...], how is the pattern compared to
> nested sub-arrays?  And so on.

Ok, I didn't think about some of these, sorry. (Now I have some things 
to think about...)

> Internally, the code is not well-organized to re-enter parameter table
> lookups during processing of multiple subscripts.  As with much of zsh,
> the parameter lookup code depends on a global value, which I hacked to be
> saved/altered/restored during associative array operations.  By the time
> you're past the first level of subscripting, it's unclear (to me, anyway)
> whether you still have all the necessary data to swap into the `paramtab'
> global for the next level of lookup.
> 
> Finally, you can get much the same effect either by careful choice of key
> names or by indirection with ${(P)...}, so it didn't seem to be necessary.
> 
> Why can't you do e.g. _args_cache_dopts[$command.$tmp]="${1#*:}" where
> $command comes e.g. from passing the name of the current command to the
> call to _arguments from the other completion functions?

Because some of them are arrays or assocs. On the expansion side we
could use `${(P)...}', of course (and I'm tempted to implement that),
but since we changed the code to disallow expansions on the left hand
side of assignments we would have to use lots of `eval's there -- and
I was just too lazy to write that (and I don't like it, I liked
being able to do `$foo=...').

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de