Lars Hellström writes:
 > > Re: efficiency: My experience is that one can have TeX do quite 
 > > extensive processing without slowing things down much *provided one does 
 > > it in the mouth*. (I don't understand quite why that would be, but did 
 > > some timing to confirm it in particular cases for fontinst v1.913.)

the "inner loop" of TeX's processing is indeed extremely fast (and
 particuarily designed to be so). But most of Tex's processing is optimized
 for speed so that I found that for arbitrary code a rough but workable
 estimate is to look at the number of lines produced by doing tracing. I found
 that this is more or less linear to processing speed, e.g. a typical mix of
 100 lines of expansions and executing primitives is about 20 times slower
 than code generating five tracing lines

 > Following up on that: As a proof of concept, I implemented (for 
 > TeX3/LaTeX2e) such a \DictGet command last night; see attached files 
 > (<6K with source documentation and tests). Complexity is linear in the 
 > size of dictionary values, but worst-case quadratic in the average size 
 > of a key.

helpful for playing around and checking alternatives, thanks.

As to the approach you outlined, I wonder if we should go in this
direction. I find it a bit dangerous if processing the  dictionary is likely
to result in expansion of the values. I mean, if I want to use a value I
essentially have to run it through a full expansion as it is unknown after how
many expansions \DictGet would return the value. For that reason it seems to
me better if one implements something like

 \dict_get:nnnN  { <key> } { <dict> } { <return-if-not-found> } <tl-variable>

so that the "value" is in <tl-variable> but without expansion, ie essentially
like the way property lists work. The tl variable can then be used in other
places without  requiring exessive expansion. This way one can avoid the
"moving argument" issue that we all know from 2e.

code for this should be still fairly fast as one could harvest the code for
plists but without the overhead  needed on updating key/values

Or am I missing something?

frank