MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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>
Message-ID:  <19841.6013.376122.141695@morse.mittelbach-online.de>
Date:         Wed, 16 Mar 2011 21:03:09 +0100
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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: expl3's seq_pop_right etc.
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <AANLkTi=KxLLEnwJsUzXe9rujQqnFX+rEFWRQq3o=v1_N@mail.gmail.com>
Precedence: list
Status: R

Hi Bruno

 > I'm attaching to this email an alternative version of l3seq, where
 > sequences are stored as \seq_elt:n {<item>}. Since it's a dtx,
 > hopefully there is enough comments in the file to follow the code, but
 > a quick overview. FYI, the ins file is at the bottom of this email,
 > and to test the package, I just make a symbolic link
 > l3seq.sty->seq-one-braces.sty and then \usepackage{expl3}.

quite a mouthful. thanks.

I took your package pushed it into my environment and first of all tried to
run our test suite against it. Of course that ended up in a huge number of
failures.

Not surprising really as you changed the interfaces.

Now, there may be good reasons for any of theses changes, but I would claim
that as an initial ste this is not helpful as it makes it difficult to compare
things and on top of it it will break a lot of code that has been already
built upon the current expl3. For example \seq:gpop:NN and its variant are
used in a good number of places. Same for \seq_map_function:NN etc

So while there there might be valid reasons while one version is superior to
another we should 

 - first discuss it
 - initially provide compatibly code
 - and only at a later stage retire something

there are a number of advantages to this most importantly for me that we can
run the test suite against the new code. So far I added

%
% \section{Compatibility}
%
%    \begin{macrocode}
\cs_new:Npn \seq_pop:NN #1#2 {
   \seq_pop_with:Nn #1 {\tl_set:Nn #2}
}
\cs_new:Npn \seq_gpop:NN #1#2 {
   \seq_gpop_with:Nn #1 {\tl_set:Nn #2}
}
\cs_set_eq:NN \seq_map_break: \seq_break:
\cs_set_eq:NN \seq_map_break:n \seq_break:n
%    \end{macrocode}
%

but that is not enough there are still several areas where the test files
for the seq module fail ... but on the whole the implementation looks already
good.

So I propose we first make your implementation support the current interfaces
(even if only by compatibility code) so that the files m3seq00... are properly
processed and in parallel discuss its individual merrits

and preferably we should at the same time write some additional tests for any
functionality that has changed or is additionally there (Joseph will tell you
that I'm pestering him about writing test cases in parallel wil code, but it
really helps to nail down interfaces and ensure that they aren't violated
later)

I haven't read the code section of your file yet, but hope that I'll find some
time later tonight or tomorrow

regards
frank