LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Will Robertson <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Thu, 10 Mar 2011 12:11:43 +1030
text/plain (2196 bytes) , seqright.tex (2834 bytes)
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