Re: Nested associations (was Re: PATCH: completion functions)

Re: Nested associations (was Re: PATCH: completion functions)

[Sven Wischnowsky]

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

Nested associations (was Re: PATCH: completion functions)

[Bart Schaefer]

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.

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?

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