LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Will Robertson <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Sun, 25 Jan 2009 02:36:00 +1030
text/plain (61 lines)

There is currently a module in the expl3 bundle for dealing with lists  
of tokens separated by commas. While there is a small application of  
these things in areas such as XeTeX's font feature selection, this is  
generally designed to offer convenient ways for users to input lists  
of things.

My question for LaTeX3 is, "are commas enough?".

The current l3doc macros define the {function} environment that uses  
vertical bar separated lists of function names:
   \begin{function}{ \seq_push:Nn | \seq_push:NC }

I've written a LaTeX2e package called mlist that deals with "math  
lists" that I define as two-d lists of items that eventually turn out  
to be functions or matrices or vectors or whatever:
   \matr{ a , b ;
          c , d }

Whether we're dealing with commas, semicolons, or vertical bars, the  
basic functions for manipulating the data would be largely identical.

There are two points of view here. One is that we should avoid making  
things more complex than they already are and highly suggest that if  
lists like this are going to be defined, then it's comma-lists or it's  

The other point of view is that we should allow some flexibility in  
how users may end up needing to input list-like data, and providing a  
range of delimited list types will be more convenient for (a) multi- 
dimensional lists such as used by mlist, and (b) not having to escape  
the delimiting characters as much; say if the list is likely to  
contain commas then you can delimit it with vertical bars instead.

I lean towards the second philosophy. My tentative proposal is to  
rename the clist module to, er, something else, and for it to  
generalise the functions in clist such that functions for new  
"delimiter"-lists can be instantiated with a single command.

I.e., the hypothetical command
   \def_delimiter_list:nn {clist} {,}
would generate the suite of functions that are currently defined in  
   \def_delimiter_list:nn {slist} {;}
might then define equivalent commands for dealing with semi-colon  
delimited lists.

* * *

Alternatively, maybe I'm taking this way too far and all we need is a  
generalised mapping function that can loop through a token list using  
an arbitrary substring as a delimiter. That would probably cover the  
majority of the cases that \def_delimiter_list would be useful for.

* * *

Any comments or further thoughts?