xparse revisited

At the recent UK-TUG meeting, I spoke about one of the most popular parts of the code written by the LaTeX3 Project, xparse. TeX-sx regulars will doubtless have come across xparse, either in one of the tagged questions or from one of the over 2400 posts featuring \NewDocumentCommand!

At the UK-TUG meeting, I was revisiting xparse following a talk I gave back in 2009. Since then, the LaTeX team have worked on xparse, we’ve learned what it’s good at and we’ve had a lot of user feedback. So it seemed like a good opportunity to take about it again.

I focussed on two areas: what xparse can do for the end user and how that leads on to seeing it’s syntax as a language for described LaTeX commands. For end users, xparse is a more-or-less complete way to describe document commands, and goes well beyond what \newcommand can do. My usual example is the syntax of \newcommand itself:

What you’ll notice here is that we can collect up all of the arguments in one place with no need to use (La)TeX code to pick up stars, multiple optional arguments and so on.

The xparse package offers several different types of argument, some of which are more common than others. Once I’d briefly outlined them, I talked about some things that xparse can do that ‘normal’ LaTeX commands can’t, for example correctly parsing nested arguments:

I also talked about how we can get more helpful error messages from TeX by some clever internal set in xparse.

Taking the idea of abstracting different kinds of LaTeX arguments took me to the concept of xparse as a language to describe LaTeX syntax. That’s not limited to being implemented in TeX, and it is also a very convenient shorthand (I use xparse-like descriptors whenever I’m taking about LaTeX commands nowadays, even if the underlying implementation is different). We had some lively discussion at the meeting about how that might fit in to efforts such as LaTeXML, and I’m sure I’ll be following that up in the future.