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:  <19843.17637.935263.780194@morse.mittelbach-online.de>
Date:         Fri, 18 Mar 2011 12:41:25 +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

now that Bruno's code appears to be providing similar functionality as the old
l3seq (at least to the extend of the test files we have) I would like to
return/get to the proposed interface changes Bruno proposed

 > - items can be any balanced text, no brace will be stripped

something we claimed but didn't actually do.
 > 
 > - I don't like the fact that \seq_(g)pop return its value locally, so
 > I changed which functions are provided there to \seq_pop_with:Nn <seq>
 > {<assignment code>}.

Im not sure here. 

 - the general design principle is that all functions that get values from
   some data structure *always* store them *locally* in a variable.

 - the data structure itself could be local or global and a manipulation of
   the structure could then be local or global too.

In my opinion this is a fairly simple rule and as far as programming
requirements are concerned it covers essentially all that is necessary.
(if one actually needs the value in some global variable then in the past one
had to move it one but in practice so far we never had any occasion where this
was necessary).

On the other hand popping + using the value is a quite common usage, so to
have to always write

  \seq_pop_left_with:Nn \l_foo_seq {\tl_set:Nn \l_bar_tl}

instead of

  \seq_pop:NN \l_foo_seq \l_bar_tl

-------------------------

now having written that I noticed that it isn't true, this is violated in
l3prop where there are gget functions for key values, so hmmm ... still I tend
towards the rule above I guess

 > - The mappings are fairly optimized as far as I can tell, and should
 > be preferred to doing things one element at a time.

not sure what you mean here. clearly if you loop directly over a sequence then
using mapping is preferable, but often when you do one element at a time the
actions are complex so that they don't quite fit into a mapping function

 > 
 > - I expect the pop_right functions to be much faster for large
 > sequences than simply storing the elements one by one.

???

 > - I'd like every "..._map_function:NN" to become
 > "..._map_function:Nn", i.e. allow mapping several tokens at a time. It
 > isn't difficult to adapt the code for that, and it would be quite
 > practical, since among the mappings, only the "map_function" are
 > expandable. For that reason, "\seq_map_function:NN" is not defined in
 > the file I attach.

Personally I don't find this very intuitive; if you map a function you map a
function name and that would mean N.  Besides you would lose the ability to map
a constructed function name ie "c" though that is something you would seldom
need I guess.

If you map several tokens then this means that you either have a bunch of
static tokens plus a final token/function that picks up the argument. Or
alternatively you map a function with several arguments (and only the last one
is filled with items from the sequence) or it is a mixture of both. None of
those scenarios feel right to me. From a programming aspect I would probably
always prefer to define my mapping function properly first and then apply it,
ie instead of

 ...map_function:Nn \l_foo_seq {<some tokens> \func:n }

I would rather do

 \cs_new:Npn \map_func:n #1 {<some tokens> \func:n #1}

 ...map_function:NN \l_foo_seq \map_func:n

This has to be done anyway if the #1 needs to be somewhere other than at the
end, eg

 \cs_new:Npn \map_func:n #1 {\func:nnn {foo}{#1}{bar}}

or what kind of application did you have in mind for ...map_function:Nn ?


my 2 cents
frank