> With all this in mind, I'd like to invite comments on the functions offered
> (perhaps an fexpandable \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/nonexpandable 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 unexpandably 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 fexpandable \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
>
>
