MIME-Version: 1.0
References: <905C5ED0-6639-4DEB-95AC-A2FCB2C4491D@gmail.com>
            <AANLkTinSd4KS9gbk_cBPseFjbTFfSmSJUgYJUUP_vpBZ@mail.gmail.com>
            <E8A13BAD-6790-4966-9BAF-379E21DD249C@gmail.com>
            <AANLkTin1PWjtDuxug+ZjGKKg=VBbuz7Pf12rCkAo9+ex@mail.gmail.com>
            <AANLkTinh=zgNFCYWuGwO4mCsL6a7Yezxec264DmWwabk@mail.gmail.com>
            <4D7D4072.1080609@morningstar2.co.uk>
Content-Type: multipart/mixed; boundary=000e0cd56d8e8e9c7b049e652204
Message-ID:  <AANLkTimngQ4WyadVu05kOhqu8u_rVdNa52u=YWE089iK@mail.gmail.com>
Date:         Sun, 13 Mar 2011 18:58:35 -0400
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:  <4D7D4072.1080609@morningstar2.co.uk>
Precedence: list
Status: R

--000e0cd56d8e8e9c7b049e652204
Content-Type: text/plain; charset=ISO-8859-1

> I need to read through everything, but as you are looking at a total
> reimplementation, more or less, do we really need two markers in a
> sequence? I've got an 'alternative' sequence system to work with just
> one (\q_seq), but at present it strips braces. (I know that because I
> checked after you started this thread: I'd have suggested my version
> otherwise!)
> --
> Joseph Wright

If we want to avoid losing braces, there are essentially two ways.
Either have two markers, `\seq_elt:w <item> \seq_elt_end:`, but the
code is tricky, or have one marker only, and braces, as `\seq_elt:n
{<item>}`. I'm essentially taking this from the TeXbook, p. 378 (and
thinking on my own, but well... I do trust Knuth's knowledge of TeX).

Will's version (and I guess yours if you use
`\quark_if_recursion_tail_stop:n`) breaks for items like
{{{{{{a}}}}}}, or some cases with conditionals. So let me also propose
a fix for `\quark_if_recursion_tail_stop:n` and friends (see attached
for examples where the current version is broken, and for the fix).
The new version should be \~10\% slower (not really checked that
claim), but would not break, although it would consider
`{}\q_recursion_tail` to be `\q_recursion_tail`.

-- 
Regards,
Bruno

--000e0cd56d8e8e9c7b049e652204
Content-Type: application/x-tex; name="quarktestfix.tex"
Content-Disposition: attachment; filename="quarktestfix.tex"
Content-Transfer-Encoding: base64
X-Attachment-Id: file0

JSBUaGUgYDpuYCBxdWFyayB0ZXN0cyBhcmUgY3VycmVudGx5IGJyb2tlbjogYm90aCBsaW5lcyBi
ZWxvdyBjcmFzaC4KJQolICAgXHF1YXJrX2lmX3JlY3Vyc2lvbl90YWlsX3N0b3A6biB7e3t7YX19
fX0KJSAgIFxxdWFya19pZl9yZWN1cnNpb25fdGFpbF9zdG9wOm4ge3thYlxpZmZhbHNlfVxmaX0K
JQolIEhlcmUgaXMgdGhlIHByb3Bvc2VkIGZpeCAoY2hhbmdpbmcgb2YgY291cnNlIGBNcXVhcmtg
IHRvIGBxdWFya2ApLiBGWUksCiUgICAgIGBcaWZfY2F0Y29kZTp3IEEgXHRsX3RvX3N0cjpuIHsu
Li59IEFgIAolIHRlc3RzIHdoZXRoZXIgey4uLn0gaXMgZW1wdHkuIEl0IGlzIGEgdmFyaWFudCBv
ZiAKJSAgICAgYFxleHBfYWZ0ZXI6d04gXGlmX21lYW5pbmc6dyBcZXhwX2FmdGVyOndOIEEgXHRs
X3RvX3N0cjpuIHsuLi59IEFgCiUgd2hpY2ggaXMgdGhlIHZlcnNpb24gdXNlZCBmb3IgYFx0bF9p
Zl9lbXB0eTpuKFRGKWAuCgpcY3NfbmV3Ok5wbiBcTXF1YXJrX2lmX3JlY3Vyc2lvbl90YWlsX3N0
b3A6biAjMSB7CiAgXGlmX2NhdGNvZGU6dyBBIFx0bF90b19zdHI6biBcZXhwX2FmdGVyOndOIHsK
ICAgIFxNcXVhcmtfaWZfcmVjdXJzaW9uX3RhaWxfYXV4OncgIzEgXHFfcmVjdXJzaW9uX3N0b3AK
ICAgICAgICAgICAgICAgICAgICAgXHFfcmVjdXJzaW9uX3RhaWwgXHFfcmVjdXJzaW9uX3N0b3Ag
XHFfc3RvcAogIH0gQQogIFxleHBfYWZ0ZXI6d04gXHVzZV9ub25lX2RlbGltaXRfYnlfcV9yZWN1
cnNpb25fc3RvcDp3CiAgXGZpOgp9Clxjc19uZXc6TnBuIFxNcXVhcmtfaWZfcmVjdXJzaW9uX3Rh
aWxfc3RvcF9kbzpubiAjMSMyIHsKICBcaWZfY2F0Y29kZTp3IEEgXHRsX3RvX3N0cjpuIFxleHBf
YWZ0ZXI6d04gewogICAgXE1xdWFya19pZl9yZWN1cnNpb25fdGFpbF9hdXg6dyAjMSBccV9yZWN1
cnNpb25fc3RvcCAKICAgICAgICAgICAgICAgICAgICAgXHFfcmVjdXJzaW9uX3RhaWwgXHFfcmVj
dXJzaW9uX3N0b3AgXHFfc3RvcAogIH0gQQogIFxleHBfYWZ0ZXI6d04gXHVzZV9pX2RlbGltaXRf
YnlfcV9yZWN1cnNpb25fc3RvcDpudwogIFxlbHNlOgogIFxleHBfYWZ0ZXI6d05cdXNlX25vbmU6
bgogIFxmaToKICB7IzJ9Cn0KXGNzX25ldzpOcG4gXE1xdWFya19pZl9yZWN1cnNpb25fdGFpbF9h
dXg6dyAjMSBccV9yZWN1cnNpb25fdGFpbCAjMgogICAgIFxxX3JlY3Vyc2lvbl9zdG9wICMzIFxx
X3N0b3AgeyAjMSAjMiB9Cg==
--000e0cd56d8e8e9c7b049e652204--