I don't have any issue with element or elt (having been exposed to lisp long time ago) but my feeling is that "length" is rather a good name for the concept, but then we should use it in other places too and get rid of elt_count there. For _nth I think _element is ok, but I'm not so sure why _item would be bad. Don't see that there would be a conflict with other "items" of LaTeX. In fact it is the same concept, so why choose different names? Frank ... written on the iPad Am 25.01.2011 um 10:37 schrieb "Robin Fairbairns" <[log in to unmask]>: > Joseph Wright <[log in to unmask]> wrote: > >> On 24/01/2011 14:01, Lars Hellström wrote: >>> Isn't this "elt" an implementation detail for that type of list (various >>> \@elt tokens in 2e come to mind), and thus something that should be kept >>> internal rather than canonised in a public interface? The clean solution >>> for *both* types of list is rather to use "length". >> >> Seems reasonable: one would normally talk about 'a long list of things >> to do', so lists to have 'length' :-) > > in some ways of looking at a list, it has 'length'. > > in plain english, i would say lists have "items" (or just "things") > rather than "elements", but "item" is already heavily overloaded in > the user's level latex-ese. i don't have a problem with "element" (or > "elt" in command names). > >>> Moreover, I get a vague impression that the term `elt' is part of the >>> pseudo-LISP heritage of LaTeX (emphasis on the "La"). If so, then that >>> is IMHO another reason to avoid it, as that heritage is full of square >>> pegs trying to fit in round holes. >> >> Not being familiar with Lisp, I can only go on things like LaTeX2e's >> \@cdr, etc., which have much more sensible names in expl3. > > the "lisp heritage" is no more than simple use of some lisp names for > some latex internal operations (e.g., car, cdr). it's a long time (>40 > years) since i learned lisp, but i don't remember a special name for > items in a lisp list. > >>>> 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 think the verb you're looking for is "index", i.e., the command name >>> would be clist_index. > > hmm. index works, but i don't think it supports the "plain english" test. > >> I'd imagine 'index' to be the other way around: >> >> \clist_index:Nn \l_some_clist { item } => Number > > agreed. > >> whereas what Will has implemented gives the 'entry', 'element', 'item' >> or some such name. ('element' seems to be discouraged based on the first >> part of your e-mail, so perhaps 'item' is better.) > > i think element is as good as it gets, in this context. > >>> first: Return index of first occurrence of a particular item within a >>> clist, >>> or -1 (given 0-based indices) if the item does not occur therein. >>> last: Return index of last occurrence of a particular item within a >>> clist, >>> or -1 (given 0-based indices) if the item does not occur therein. >>> (Note: Slightly trickier to implement.) >> >> Both of these look relatively easy to do. >> >>> range: Return a subrange of the clist, i.e., if \a_clist is "a,b,c,d" then >>> \clist_range:Nnn\a_clist{1}{2} returns "b,c". (I don't have an >>> opinion as to what might be the best sense of "return" in this >>> case.) >>> replace: Replace the material in a subrange of the clist by some other >>> clist material. >> >> More tricky. Let's sort the others first :-) > > robin > > getting better every day. very slightly.