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>
            <19843.17637.935263.780194@morse.mittelbach-online.de>
            <AANLkTin649=nq1Rhtttk3vqBD9nNytZ6uO+hU=gcevAw@mail.gmail.com>
Message-ID:  <19843.47932.785350.652072@morse.mittelbach-online.de>
Date:         Fri, 18 Mar 2011 21:06:20 +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:  <AANLkTin649=nq1Rhtttk3vqBD9nNytZ6uO+hU=gcevAw@mail.gmail.com>
Precedence: list
Status: R

Bruno,

 > To be clear, I'm perfectly ready to keep the old interface. I was
 > mostly concentrating on the implementation, and some functions
 > appeared more natural than the existing ones in that context.

I'm not saying that the old interfaces need to stay or should stay, only that
it is helpful if they do at least initially. And the discussion so far shows
(and showed in the past) that there are improvements possible.

By the way, with the interfaces but back in the compatibility section shows
some failures in some files that need checking. Not really got around checking
for cause. 

xor certainly dies because some of its code misuses the seq implementation and
hacks into \seq_elt:w so not surprising this dies. For others I don't know
yet.

 > > > Then there is the issue of l3candidates, which I have not
 > > > re-programmed yet, as well as the quicksort defined in l3prg.dtx
 > >
 > > one step at a time i'd say.
 > 
 > I meant that there are some \seq_from_clist and \clist_from_seq
 > functions in l3candidates which will have to be rewritten, and a
 > \seq_quicksort, or something like that, which I haven't looked at. I'm
 > _definitely not_ rewriting l3prg.dtx :).

you are not? :-) pity.  But this is what I meant: none of these are on the
critical path. So I was just agreeing with you that there is no need to
rewrite them just to experiment with a new seq implementation. Of course if we
decide to adopt it, then we need to do those rewrites, eventually.


 > >  > - 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.
 > 
 > Is there any example of data structure other than seq or prop?

not much at the moment in terms of kernel data structures, only clists I
think. But for the outputroutine and the like I guess you will have other
complex data structures from which you need to pick up values.

 > 
 > 
 > > 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
 > 
 > I see your point. Then perhaps renaming \seq_pop_left_with:Nn to
 > \seq_pop_left_do:Nn, and leaving \seq_pop:NN as it is could make
 > sense. Then if we just want to remove the left-most element and apply
 > some function onto it, we can do
 > 
 > \seq_pop_left_do:Nn \l_foo_seq {\foo:nn {<arg1>}}
 > 
 > and to get a global return value we would do
 > 
 > \seq_pop_left_do:Nn \l_foo_seq {\tl_gset:Nn \g_foo_tl}
 > 
 > Basically, I'm just making an auxiliary function available to the user.

I must say I rather like \seq_pop_left_with:Nn as a generic approach. It is
just that I don't want to drop the function that one normally needs for it.
And I rather prefer the _pop_with to _pop_do. 

As to the naming, of course one could go for

 \seq_get_pop:NN

or even

 \seq_get_pop_left:NN

and then one could have all variations without any ambiguity to what is local
and global, eg

 \seq_gget_pop:NN
 \seq_get_gpop:NN
 \seq_gget_gpop:NN

perhaps that's better but I'm not sure if it is not just making things longer

 > 
 > > 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
 > 
 > I think that you are right: there should be a \..._pop_left:NN, which
 > does something consistent between the various data structures.
 > Choosing local return values is as good as anything.

Well I'm not too sure myself here, the discussion is certainly helpful


 > >  > - I'd like every "..._map_function:NN" to become
 > >  > "..._map_function:Nn", i.e. allow mapping several tokens at a time. It
 > >
 > > 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.
 > 
 > My initial application was to be able to map a function with two
 > arguments on two seq <a> and <b> at the same time. First I zipped the
 > two seq into one seq whose item each have the form {<a_i>}{<b_i>}.
 > Then I could map _expandably_
 > 
 > \seq_map_function:Nn \l_foo_zipped_seq {\exp_after:wN \foo_func:nn \use:n}
 > 
 > where the \use:n unbraces its argument. Not a very convincing use.

No not really :-) if it is a serious use I would probably encapsulate it by
its own functions and then use those, but anyway ...

 > But Lars Madsen's examples with { \foo_func:nn {arg1} } are better.

yes probably 

 > > 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
 > 
 > That would be better as
 > 
 > ...map_inline:Nn \l_foo_seq {<some tokens> \func:n {#1}}
 > 
 > The key here is expandability. When it is not needed, map_inline:Nn
 > and map_variable:NNn fit the bill nicely. The best might be to leave
 > both the :NN and :Nn variants, synonyms of each other, hence taking
 > little of TeX's memory.

probably. 

 > There is also the question of whether removing an elements once/all
 > copies of it should be named as in l3clist or l3tl:
 > 
 >    \clist_remove_element:Nn
 >    \tl_remove_all_in:Nn
 >    \tl_remove_in:Nn
 > 
 > I'd go for the tl version.

agreed some concistency in the naming would be in order. About the actual
names  to use I'm not so sure. Must confess I wasn't aware of the tl ones at
all.  The _in seems to me unnecessary and I would personally prefer

 \tl_remove_once:Nn
 \tl_remove_all:Nn

etc.

cheers
frank