Should expl3 code be used in packages intended to be compatible with multiple formats?

Question

_{Maybe this question is just not a good idea in general, but, I'm curious. This could make package development simpler for some in the future. (Of course, this would not be forced on any package developer, but he/she could choose to use this approach or the traditional approach.) I guess the real key is that it could provide additional options for those who wished to use them.}

---

Numerous packages¹, including two I use quite frequently (pgf and pgfplots) are implemented in a generic way that makes them usable with multiple formats. In the case of pgf/pgfplots, these "packages" work equally well in Plain TeX, LaTeX, and ConTeXt documents.

To accomplish this goal (ensuring compatibility with many formats), the code uses TeX primitives for implementation as a "common denominator". As a result, the code is full of \expandafters, end-of-line %s, and all sorts of other TeX programming constructs that expl3 syntax aims to abstract away from the programmer. (Not unlike LaTeX's original aim of abstracting these away from the typical document author.)

Along the lines of miniltx and eplain, I imagine that all or some subset of expl3 might be provided for use by format-agnostic package developers. When researching this question, I discovered that this possibility seems to be already available in the form of expl3-generic.tex that \inputs the core expl3 code (expl3-code.tex) in a format-neutral way.

• Was this design choice made with these types of uses in mind, or was there another reason to structure the code in this way? (Ease of low-level testing, for instance.)
• Do any current or in-development sets of format-neutral macros ("packages") use this approach?
• Finally, along the lines of the title: Is this a recommended practice? Should format-neutral packages (at the discretion of their authors, of course) use expl3 syntax/conventions internally?

---

¹ Check your TDS tree at texmf-dist/tex/generic for some examples.

Answer 1

The core purpose of expl3 is to form the programming layer for wider development of new LaTeX tools. At present, this work is carried out on top of the LaTeX2e format and so expl3 was conceived as a LaTeX2e package. However, expl3 is quite self-contained, putting all TeX primitives into a dedicated namespace and using them to build up the code environment. As a result, the idea of providing a version of expl3 which can be loaded by formats other than LaTeX2e was first suggests some time ago, but only effected recently.

The implementation of expl3 such that it can be loaded by different formats was done precisely to allow the code to be used with multiple formats. This followed a request from the user community. Thus the cross-format nature of expl3 is intended to allow developers to use the code base to support their work. Importantly, only expl3 is currently set up to load in this way: the same is not true for any additional expl3-based code (e.g. l3regex).

As to whether one wishes to use this ability, it will come down to the developers involved. For some developers of generic code, dependencies are to be avoided and indeed working at the 'bare metal' primitive level may be regarded as a positive factor. On the other hand, if you find expl3 to be a useful development environment then this is your call and you are free to use it to support your work. For example, the team are using the generic loading ability of expl3 to write scripts which execute in plain but with the richer set of tools available when using the coding environment.

It is important to remember that expl3 only provides a code layer and thus anything 'higher level' will still have to be handled on a per-format basis.

---

If you want to use expl3 in generic mode, the generic loader is called using

\input expl3-generic\relax

If used with LaTeX2e this will switch to the standard package, whilst for plain TeX and ConTeXt it will load as-is. At present, generic loading has not been tested with other formats.

Note that the graphics driver selection in generic mode always goes with the automatic driver selections. This means that (currently) working with dvipdfmx specials is not possible. If there is a significant need this may be re-examined.

Answer 2

^{These are the recollections and opinions of a mere mortal.}

Was this design choice made with these types of uses in mind, or was there another reason to structure the code in this way? (Ease of low-level testing, for instance.)

As David notes in the comments and Frank noted in chat, this choice was made deliberately. I suspect it was largely driven to separate further the ideas of logic, interface, presentation, and content. That said, the language was also clearly designed to be very structured: a great deal of thought seems to have gone into its design and implementation to keep the good parts of TeX programming, abstract away the bad parts, and solve real modern typesetting problems while providing a relatively sane programming environment.

The rigid structure of expl3 helps everyone.

Do any current or in-development sets of format-neutral macros ("packages") use this approach?

Well as a matter of fact, yes :-) termmenu (currently in active development; I swear I didn't write it just for this question) uses solely expl3 to implement a terminal-driven menu system.

lt3graph could also easily be made format-agnostic, but alas: it is not. Note that this too is primarily an extension of the expl3 programming language.

I think that this idea of extensions (in expl3-speak, 'modules') is what will drive expl3 development forward in the community. LaTeX3, using expl3, will drive development for LaTeX.

Finally, along the lines of the title: Is this a recommended practice? Should format-neutral packages (at the discretion of their authors, of course) use expl3 syntax/conventions internally?

I recommend it where it makes sense. If you're creating something that is solely a programming problem, then absolutely implement it with expl3. If it has a presentation element, however, keep the layers separate. Either make it completely a LaTeX package or peel away the pure logic into an expl3 module.

In any case, don't forget your prefix :)