For programming packages that implement new functionality for LaTeX2e what you mainly need is the programming layer of LaTeX3.
xparse
additionally offers you some help for defining user interfaces in 2e style with optional arguments or star forms etc, but you can think of this as the syntactic sugar on top of the functionality your package provides. And in the opposite direction, xparse
is also quite useful standalone, i.e., if you define commands using 2e methods and just want to have a more powerful user interface setup.
template
finally is something that I think is right but not ready so I would use this only with caution. I'll expect later this year to to see more of the designer interface foundation layer to become available, but right now you would need to be at least prepared for possibly larger interface changes. You asked for documentation on templates: there is of course the template file itself: template.dtx
but there is also a short paper by Lars and some related articles on the project website.
The LaTeX3 programming layer
Concerning documentation of the programmin layer of LaTeX3 (aka expl3
) I suggest reading the following documentation (in order):
expl3.pdf
Some introductory notes on some of the concepts
interface3.pdf
The full interface description of all functions of the LaTeX3 programming layer as released. There are a number of modules that are not yet part of the stable kernel (in the directory l3kernel
), but what is in this document is the description of everything we consider "stable".
Smaller changes are possible though and programmers making use of l3kernel
are strongly encouraged to subscribe to
the LaTeX-L mailing list: announcements concerning the deprecation
or modification of functions are made on the list.
This document is a reference document so functions are document by module and not really a manual for learning the language --- sorry the latter doesn't yet exist. It also doesn't give you many examples of how to use the constructs but rather documents the specific interfaces.
source3.pdf (don't read (initially) :-)
For understanding of how this is implemented one can read source3.pdf
which gives both the specification as well as the full documented code. However, I suggest not to start with this for a couple of reasons:
- The core modules implement data structures and functions that are essential for building higher-level constructs. For this reason they are (at least if they are likely to be needed often) tailored for speed and that means that some of the tricks used there are not appropriate for coding outside the kernel
- The core modules are build on top of the primitives of TeX so they can only partially make use of the core concepts of
expl3
. For example, you will find a lot (about 450) uses of \exp_after:wN
(also known to us as \expandafter
) while I would claim that in normal expl3
programming outside the kernel this command should never or hardly ever be used.
How to use the programming layer
A better starting point for looking at how to use the LaTeX3 programming layer are the examples that have been given in replies to questions on this site and also perhaps something like the higher-level modules. At this point in time in the kernel directory there is only l3coffins.dtx
that I would recommend for this. More will follow over time.
(I guess I could be called a member of one of the teams ;-) this is my view)
I thought of staying out of this debate, but perhaps some words of clarification or, let's say, some thoughts are in order after all.
LaTeX3 versus pure Lua
First of all this is the wrong question imho: LaTeX3 has different goals to LuaTeX and those goals may well be still a defunct pipe dream, but if so they are unlikely to be resolved by pure Lua either.
So if one wants to develop an argument along those lines then it should be more like "Why does LaTeX3 use an underlying programming language based on eTeX and not on LuaTeX where a lot of functionality would be available in a "simpler" way?"
But LaTeX3 is really about three to four different levels
- underlying engine
- programming level
- typesetting element layer
- designer interface foundation layer
- document representation layer
See for example my talk at TUG 2011: http://www.latex-project.org/papers/
Here is a sketch of the architecture structure:
The chosen underlying engine (at the moment is any TeX engine with e-TeX extension). The programming level is what we call "expl3" and that is what I guess you are referring to if you say "LaTeX3" (and I sometimes do that too). However, it is only the bottom box in the above diagram. The more interesting parts are those that are above the programming level (and largely a pipe dream but moving nicely along now that the foundation on the programming level is stable). And for this part there is no comparison against Lua.
Why use LaTeX3 programming over Lua, when LuaTeX is available?
To build the upper layers it is extremely important to have a stable underlying base. As @egreg mentioned in chat: compare the package situation in 2.09 to the package situation in 2e. The moment there were standard protocols to build and interface packages the productivity increased a lot. However, the underlying programming level in 2e was and is still a mess which made a lot of things very complicated and often impossible to do in a reliable manner. Thus the need for a better underlying programming layer.
However, that programming layer is build on eTeX not because eTeX is the superior engine (it is compared to TeX but not with respect to other extensions, be it Lua or some other engine) but because it is a stable base available everywhere.
So eTeX + expl3 is a programming layer that the LaTeX3 team can rely on of not being further developed and changed (other than by us). It is also a base that is immediately available to everybody in the TeX world with the same level of functionality as all engines in use are implementing eTeX extensions.
Any larger level of modifications/improvements in the underlying engine is a hindrance to build the upper layers. True, some things may not work and some things may be more complicated to solve but the tasks we are looking at (well I am) the majority are very much independent of that layer anyway.
To make a few examples:
good algorithms for automatically doing complex page layout aren't there (as algorithms) so Lua will not help you here unless somebody comes up with such algorithms first.
something like "coffins", is thinking about approaching "design" and the importance here is how to think about it, not how to implement it (that comes second) -- see Is there no easier way to float objects and set margins? or LaTeX3 and pauper's coffins for examples
Having said that, the moment LuaTeX would be stable similar to eTeX (or a subset of LuaTeX at least) there might well good reasons for replacing the underlying engine and the program layer implementation. But it is not the focus (for now).
Why use LaTeX3 to program at all? Why not turn its development into the development of a LaTeX-style document design library for LuaTeX, written in Lua?
Could happen. But only if that "LuaTeX" would no longer be a moving target (because LaTeX3 on top would be moving target enough).
Side remark: @PatrickGundlach in his answer speculated that this
answer that the LaTeX3 goal is backwards compatibility. Wrong. The
same people that are coming down on you very strong about
compatibility for LaTeX2e have a different mindset here. We do not
believe that the interesting open questions that couldn't get resolved
for 2e could be resolved in any form or shape with LaTeX3 in a
document-compatible manner.
Input compatible: probably. But output compatibility for old
documents, no chance if you want to get anything right.
But in any case, this is not an argument for or against implementing the ideas we are working on one day with a LuaTeX engine.
Is the separation of LuaTeX and LaTeX3 a result (or at least an artifact) of the non-communication among developers that Ahmed Musa described in his comment to this answer? What kind of cooperation is there between these two projects to reduce duplication of effort?
As I tried to explain, there is not much overlap in the first place. There is much more overlap in conceptual ideas on the level ConTeXt viz. LaTeX.
An even more fantastical notion is to implement every primitive, except \directlua itself, in terms of Lua and various internal typesetting parameters, thus completely divorcing the programming side of TeX from the typesetting side.
That brings us to a completely different level of discussion, namely is based on LuaTeX, or anything else for that matter, a completely different approach to a typesetting engine possible? That is a very interesting thought, but as @Patrick explained it isn't done with leaving TeX to do the typesetting and do everything else in a different language. So far such concepts have failed whether it was NTS or anything else because fundamentally (in my believe) we haven't yet grasped how to come up with a successful and different model for the TeX macro approach (as ugly as it might look in places).
Best Answer
I believe it is good practice. There are hundreds of functions in the current LaTeX3 kernel that make a macro programmer's life easier.
I wouldn't use such a dramatic indentation as you do and surely I'd use
\NewDocumentCommand
:or, even better,
separating the user command from the inner function. This may be easily extended to any number of intersection points
Notice the use of
~
to denote a space in the output, to be preferred to "control space". One may add a check that the number is greater than zero.Notice also that
\prg_case_int:nnn
is an obsolete name for the current\int_case:nnn
function.Why
\cs_new:Npn
? Because the\int_compare:nTF
and\int_case:nnn
functions are marked with a filled star in the documentation, so they are "fully expandable" and thus also\ellett_tangentcount:n
can be used in a "pure expansion" context.