> With all this in mind, I'd like to invite comments on the functions offered > (perhaps an f-expandable \seq_get_(left/right):N would also be a good idea? > Contributions welcome.) and the particular implementation I've chosen below. > After any discussion here I'll add the functions (with tests) to expl3. I'll give a try to various variants f-/x-/non-expandable this weekend, and benchmark them. Do we care about keeping braces surrounding an element in a sequence (I'd say yes, although it requires more care)? -- Bruno On 3/9/11, Will Robertson <[log in to unmask]> wrote: > Dear all, > > Quite some time ago Morten and I were discussing improvements to the > functions offered by the "seq" module in expl3, namely to make symmetric the > push and pop commands so you could access them on both sides if you wished. > (Obviously, perhaps, it's more efficient to do things on the left, however.) > > The idea is that where the seq module currently offers > > PUT LEFT \seq_put_left, \seq_push (synonyms) > PUT RIGHT \seq_put_right > POP LEFT \seq_pop:NN > POP RIGHT <none> > GET LEFT \seq_get:NN, \seq_top:NN (synonyms) > GET RIGHT <none> > > we would augment/rename these functions as follows: > > PUT LEFT \seq_put_left, \seq_push > PUT RIGHT \seq_put_right > POP LEFT \seq_pop_left:NN, \seq_pop:NN > POP RIGHT \seq_pop_right:NN > GET LEFT \seq_get_left:NN, \seq_get:NN > GET RIGHT \seq_get_right:NN > > I've finally taken some minutes to write out some functions that fill in > these gaps. > > There are a few design decisions that I've chosen to delay -- e.g., should > we be aiming for more expandable functions for dealing with sequences? My > thoughts are that it's probable that expandable functions are faster for > shorter lists and slower for longer ones, although I haven't done any > benchmarking. So my first reaction is to do everything expandably with comma > lists but un-expandably with sequences. However, my implementation actually > does use the mapping approach since we've got that conveniently set up with > quarks already. Happy to discuss. > > With all this in mind, I'd like to invite comments on the functions offered > (perhaps an f-expandable \seq_get_(left/right):N would also be a good idea? > Contributions welcome.) and the particular implementation I've chosen below. > After any discussion here I'll add the functions (with tests) to expl3. > > In lieu of code comments, a rough description: sequences are mapped two > elements at a time until the end of the sequence is reached. For the > pop_right:NN operations, a new sequence is put_right into until the final > element is found and omitted but stored in a token list. For the get_right > operations, we simply save the final element in a token list. There is also > a pop_right:N function offered that does not store the popped element. > > Best regards, > -- Will > >