MIME-Version: 1.0
References: <905C5ED0-6639-4DEB-95AC-A2FCB2C4491D@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <AANLkTinSd4KS9gbk_cBPseFjbTFfSmSJUgYJUUP_vpBZ@mail.gmail.com>
Date:         Thu, 10 Mar 2011 22:03:17 -0500
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: expl3's seq_pop_right etc.
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <905C5ED0-6639-4DEB-95AC-A2FCB2C4491D@gmail.com>
Precedence: list
Status: R

> 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 <wspr81@gmail.com> 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
>
>