# Promoting xparse


\documentclass{article}
\usepackage{xparse}
\NewDocumentCommand\en{g}{%
\IfNoValueTF{#1}{\epsilon}{\epsilon_{#1}}%
}
\begin{document}
$$\en$$ and $$\en{stuff}$$.
\end{document}

This is clear, and does not need any knowledge of the internals of the LaTeX3 approach. So I’m going to keep promoting xparse for day to day LaTeX users, even if they aren’t using much code. Hopefully this will make life easier for them, and for me, and will be a real benefit now from the LaTeX3 work.

### 5 thoughts on “Promoting xparse”

xparse can be used for very interesting things. I have one question though:

Why does it allocate two writes, when in most cases those writes are not used? At least my own hacks to release them does not seem to cause problems in my use of xparse.

This becomes a problem in large projects where one is running out of writes.

Why was the number of writes/reads not increased by etex with the rest of things?

2. Joseph Wright

I can’t speak for e-TeX, although I’d guess that this is because file operations have a “cost” at the OS level.

On xparse, I don’t follow. There should not be any reads or writes involved in xparse: can you provide an example (including listfiles)?

One thing I would add is that the I/O unit for expl3 provides a much more flexible approach to opening reads and writes than the one used by LaTeX2e. It implements a pool, so as long as programmers are sensible (closing I/O once they’ve finished with it) then we should have much less risk of running out. See what I’ve done in notes2bib, for example, where I don’t need to know anything about the shipout so can have a one-shot I/O at the end of the document.