Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
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>
            <935A1EA2-C971-4A3A-8DF4-6F890E0CFB32@gmail.com>
            <5256FD2C-CD53-4FF0-A405-5B8B2781E5EC@gmail.com>
            <AANLkTinfC5YVmG57GhGsFAddi1jy7PiZ+6cjV1Wx7KCD@mail.gmail.com>
            <A30A1074-CC53-495E-864C-91180793D8FB@gmail.com>
            <AANLkTi=KxLLEnwJsUzXe9rujQqnFX+rEFWRQq3o=v1_N@mail.gmail.com>
            <19843.17637.935263.780194@morse.mittelbach-online.de>
            <AANLkTin649=nq1Rhtttk3vqBD9nNytZ6uO+hU=gcevAw@mail.gmail.com>
            <19843.47932.785350.652072@morse.mittelbach-online.de>
            <AANLkTik0E_sURh3ofc3oGn2NsjcAATKRtzNNJuYcC9pw@mail.gmail.com>
            <7F71B7CB-A004-49DC-B178-D9CF58DA93A2@gmail.com>
            <AANLkTik_JAifStmByXjCqk-YM4gxuFEdeAL1OPeFJ1_p@mail.gmail.com>
Content-Transfer-Encoding: 8bit
Message-ID:  <08C15662-D17F-41A5-9709-CE0C244BF398@gmail.com>
Date:         Tue, 22 Mar 2011 00:39:27 +1030
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: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: expl3's seq_pop_right etc.
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <AANLkTik_JAifStmByXjCqk-YM4gxuFEdeAL1OPeFJ1_p@mail.gmail.com>
Precedence: list
Status: R

On 21/03/2011, at 11:00 PM, Bruno Le Floch wrote:

> Another question I noticed is whether mappings should be made nestable
> or not. I _think_ that \seq_map_function:NN is nestable, and that
> \seq_map_inline:Nn and \seq_map_variable:NNn are not. All three can be
> made expandable, I believe. Should they?

Indeed they should.
I ran into this problem just the other day and left a note to come back to this issue :)


> A modus operandi to easily switch to the proposed l3seq would be first
> to get rid of all the explicit \seq_elt:w ... \seq_elt_end:, for
> instance by replacing \seq_show:N by \seq_display:N in testfiles, and

I've actually wondered if \seq_show:N is really needed at all, but we've never come up with a good enough argument to drop it completely in favour of \seq_display:N.

I've updated a small handful of test cases to use \seq_display:N instead, but there are many more examples that use \meaning (etc.) that probably need adjusting.


> replace ad hoc constructs by some \..._map_inline where possible.

It's just a few in xor, right?

Looking in say \xor_save_area_info:n, perhaps all it needs is for \seq_elt:w and \seq_elt_end: to be \protected, and then their reassignment to \relax could be avoided. Haven't tried, though.

	
> If something slightly more advanced (e.g. some things in Will's
> version of the NFSS) is needed, I'm happy to code two versions:
> - with \seq_elt:w ... \seq_elt_end: now, so that everything is in
> l3seq (or l3candidates)
> - with \seq_elt:n for later when/if we switch.

I have to admit I'm more comfortable to first expand what we've currently got (extra functions, smooth over some extra edge cases, etc.) and then consider switching to a different internal format after the first stage is complete.

But if we adjust these test cases and it seems that switching to the new internal format "just works", then I'm open to diving in head-first so to speak.

'Night,
-- Will