LaTeX3 provides the two modules seq and clist.

What is the difference?

The module clist is introduced by

Comma lists contain ordered data where items can be added to the left or right end of the list.

The module seq is introduced by

LaTeX3 implements a “sequence” data type, which contain an ordered list of entries which may contain any balanced text.

What are the benefits and drawbacks of the modules?


The two modules share a lot of features, and at there are many tasks which can in principle be tackled using either. To understand the reason for the existence of both, I'll first highlight what seq can do that clist cannot.

A comma-separated list looks something like


which means that most obviously the items cannot contain a comma (without brace protection). On the other hand, the seq data type is constructed such that an item may contain any balanced text. That includes not only commas, but also crucially empty entries.

The latter point occurs because a comma list is essentially a 'user facing' structure, whereas a sequence is meant for programmers. You'll also see this if you try adding a space to a comma list: spaces are trimmed from comma list items, and so something like

a, b , , c , d

is treated identically to


As sequences have an internal structure to support programmers, it's also possible to optimise the implementation rather more than it is for comma lists. That has consequences for performance in some cases.

So in terms of which is appropriate, I would favour comma lists when dealing with stuff toward the user level, for example where user input/output is required. On the other hand, totally arbitrary lists of items are better handled as sequences. There is an element of personal preference in the middle ground (where both will work).

In the past, I have suggested dropping clist functions entirely except for a conversion layer (so that we would have a single 'true way'). However, if cases where basically everything can be handled using a comma list there is a performance hit to this that is hard to justify.

  • I still don't understand what need there is for clist. From your answer it sounds like it's entirely redundant. You mentioned in the end that dropping clist would incur a performance hit, but then earlier in your answer you wrote that sequences have a more optimized implementation than comma lists. And a comma list literal can always be converted to a sequence with \seq_set_split:Nnn \l_my_seq {,} {<token list>}, and converted back to a comma separated list with \seq_use:Nn \l_my_seq {,}. – Evan Aad Sep 29 '17 at 15:18
  • @EvanAad Comma lists are very common and handy as you can type them in directly (a lot of the time you don't need empty entries or the like). There's a performance hit to any conversion, so for example if we have a comma list input and then do a mapping, with no complex manipulation, we avoid the two-steps we'd need if we dropped clist functions entirely. There's also the case where both the input and the result are comma lists: two conversions would be somewhat over the top. – Joseph Wright Sep 29 '17 at 15:49
  • @EvanAad I was the person suggesting we drop clist ('one true way'), and in the end it didn't feel that great a plan. Contrast the old toks module, which we dropped when we made tl general. (You might need to look a long way back in the SVN to see this, so tl might be called tlp!) – Joseph Wright Sep 29 '17 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.