Why isn't xparse a part of expl3?

Why does xparse exist at all? Isn't expl3 good enough?

Is there a situation where both should be used?

When should I prefer one over the other?

  • expl3 is a programming layer written in TeX; xparse is a package that uses expl3 to bring flexibility to user defined document commands. In other words, expl3 is a cool material named graphene that is the “newest thing”, and xparse is just a figure made of graphene (an useful one). – Manuel Sep 22 '17 at 7:25
  • @Manuel: What makes xparse useful? What is the advantage of using xparse over expl3? – Evan Aad Sep 22 '17 at 7:28
  • There's no “over” there. xparse is useful to define commands like \foo[optional]{mandatory}, or \foo[optional][optional](optional), or \foo*{mandatory, and the asterisk optional}. expl3 has nothing to do with that, it just happens that xparse is written itself with help of the expl3 commands. You don't have to choose. There's no choice. The same way you don't choose between drinking and taking a shower, or you don't choose between eating spinach and having a pair of gloves, they are two different things that serve different purposes, there's no “choice”. – Manuel Sep 22 '17 at 7:33
  • there is almost no overlap in functionality so the question of which to use doesn't arise. – David Carlisle Sep 22 '17 at 7:46

One of the aims of the work of the LaTeX Project is to separate out the various different aspects of using TeX to create documents into defined layers, each with an appropriate API. For programming we have expl3: it is the 'base layer' for all other work and provides an approach documented without using 'raw' TeX primitives.

The xparse package sits at a different layer, that of creating document interfaces for code-level functionality. There are a number of document command syntaxes one could imagine, and xparse provides one of these: a LaTeX2e-like one. One can imagine using the same code level material with a different interface system to for example typeset straight from Markdown, XML, ... Today it is likely that any future format will stick to a 'native' LaTeX2e-like interface, with scripts for conversion, but this was not always so clear.

Experience with LaTeX2e tells us that directly creating document commands along with implementation is awkward: one has to worry about the interface when altering the implementation, and vice versa. By using xparse the programmer can separate out the two aspects: the interface in xparse 's o m' syntax, the implementation in documented expl3 functions (or otherwise).

As such, there is no competition between the two parts: xparse is implemented in expl3 in the same way TeX is implemented in Pascal (WEB).

To be clear, a document interface is for example the fact that \section takes an optional star, and optional argument in square brackets and a mandatory argument: it defines how a 'LaTeX(2e)-like document' looks. The code-level implementation is (or would be) taking those three concepts ('TOC Entry', 'Short title', 'Full title') and implementing the typesetting. The latter doesn't have to be tided to any particular document syntax, so we might imagine

\DeclareDocumentCommand \section { s O{#3} m }
     \sectioning_create:nnnN { 1 } {#3} {#2} #1 

where \sectioning_create:nnnN takes arguments

  1. The outline level
  2. The 'full' text
  3. The 'short' text
  4. The TOC flag

Or we might change that so the optional argument to \section is a keyval, thus changing the implementation but not the interface

       \keys_set:nn { sectioning } {#2}
       \sectioning_create:nnN { 1 } {#3} #1

which has the same document-level interface but different implementation.

| improve this answer | |
  • Thanks. I don't understand what "document interfaces for code-level functionality" means, and what the difference is between this expression and simply "programming". – Evan Aad Sep 22 '17 at 7:48
  • Also, what do you mean by "the same code level material with a different interface system to for example typeset straight from Markdown, XML"? Can you give an example of such an XML-based system? Do you mean that a .tex document will look like an XML document? – Evan Aad Sep 22 '17 at 8:07
  • @EvanAad At least in principal one doesn't need a .tex document at all: it is possible to create a format that natively reads XML and typesets using TeX without converting to any 'recognisable' TeX-like intermediate format. That is probably not the way we'd go today: more likely to use a scripting language to turn XML into some TeX format then typeset that. – Joseph Wright Sep 22 '17 at 8:16

Your Answer

