User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13)
            Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
References: <201101230906.p0N96bln024353@comedy.dante.de>
            <A246A33A-C2AA-4B72-A614-C720E0DB0CD0@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4D3C4934.50606@morningstar2.co.uk>
Date:         Sun, 23 Jan 2011 15:28:52 +0000
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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: \clist_length:N and \clist_nth:N
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <A246A33A-C2AA-4B72-A614-C720E0DB0CD0@gmail.com>
Precedence: list
Status: R

On 23/01/2011 09:12, Will Robertson wrote:
> Begin forwarded message:
> 
>> Subject: [l3svn] r2135 - add \clist_length:N and \clist_nth:N to l3candidates
>> Author: will
>> Date: 2011-01-23 10:06:37 +0100 (Sun, 23 Jan 2011)
>> New Revision: 2135
>>
>> Modified:
>>   trunk/l3in2e/l3candidates.dtx
>> Log:
>> add \clist_length:N and \clist_nth:N to l3candidates
> 
> 
>>From a question on tex.se (http://tex.stackexchange.com/q/8626/179), I finally got around to writing \clist_length:N and \clist_nth:Nn functions for extracting the length of a comma list, and extracting the n-th element of the same. Both are expandable. (Code attached below.)
> 
> Questions: names? I think "length" is a good one although it doesn't match \tl_elt_count:N which is the equivalent for arbitrary token lists.
> 
> I didn't write "clist_nth" with a view of it being the permanent name, but now that I've written it I can't think of a (good) alternative. Any thoughts?
> 
> I assume that other packages dealing with comma-lists (such as etoolbox, etc.) contain similar functions. Is there functionality in l3clist that we're currently missing?
> 
> Best wishes,
> Will

Hello Will,

I'm happy with the idea in principal, but not the names or the
implementation :-)

On the names, we currently have \tl_elt_count:N, so should really follow
the model and have \clist_elt_count:N. On the other hand, I notice that
there are various other uses of 'element' in other functions. So perhaps
we'd be better having \tl_element_count:N and \clist_element_count:N,
and not using 'elt' at all. (We also need :c and :n variants.)

For \clist_nth:N, I'd prefer '\clist_element:N'. We don't want 'get'
here as that is used in non-expandable assignments (see \prop_get:NnN,
etc.).  'nth' is really awkward, I think.

On the implementation, there are some things to think about. You've gone
for an implementation indexed from 1, which gives an error with 'out of
range' cases. In other places we've indexed from 0 (as TeX does for
\ifcase), and we need to cover negative numbers. I'd prefer to avoid two
loops, and also think that 'out-of-range' values should simply result in
an empty value, not an error.

Based on that, I'd go for:

  \cs_new_nopar:Npn \clist_element:Nn #1#2 {
    \exp_args:No \clist_element:nn {#1} {#2}
  }
  \cs_new:Npn \clist_element:nn #1#2 {
    \int_compare:nNnF {#2} < { 0 }
      {
        \clist_element_aux:nw {#2} #1
          , \q_recursion_tail \q_recursion_stop
      }
  }
  \cs_new:Npn \clist_element_aux:nw #1#2 , #3 {
    \int_compare:nNnTF {#1} = { 0 }
      { \use_i_delimit_by_q_recursion_stop:nw {#2} }
      {
        \quark_if_recursion_tail_stop:n {#3}
        \clist_element_aux:nw { #1 - 1 } #3
      }
  }

(The implementation in etextools is indexed from 0, by the way.)

We should also provide the same for sequences. They, of course, can
include empty values, but I'd think a similar approach would be best.
--
Joseph Wright