LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Sun, 23 Jan 2011 15:28:52 +0000
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=ISO-8859-1
From: Joseph Wright <[log in to unmask]>
Parts/Attachments: text/plain (75 lines)
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

ATOM RSS1 RSS2