## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: expl3's seq_pop_right etc.

From:

Date:

Wed, 16 Mar 2011 21:03:09 +0100

Content-Type:

text/plain

Parts/Attachments:

 text/plain (67 lines)
 Hi Bruno  > I'm attaching to this email an alternative version of l3seq, where  > sequences are stored as \seq_elt:n {}. 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