The programming language introduced by
expl3 in LaTeX3 is a bit unusual compared to other TeX macro languages in that it uses both _ and : for function names. Could someone provide some technical insight on the pros and cons of the syntax?
Disclaimer: originally the question was phrased as like/dislike instead of pros/cons, and that is the only way in which I can provide an answer. I do not have enough practical experience in expl3 to comprehend the technical (de)merits of the language. So this answer is an (outside) opinion piece only.
To readers that know my background as one of the luatex and ConTeXt developers it should come as no surprise that I do not like the new syntax.
My main objection is that it adds additional complexity to a task (macro programming) that is already highly complex.
Taking the definition of
This looks like I would have to learn a completely new programming language that looks similar to, but is clearly not the same as, TeX macros. Taking into account that it took me more than a year at a full-time job to learn how to write TeX macros properly, this scares me quite a bit.
In the example, the naming of the internal macros and the use of a comma-separated list suggest that the intent is to make macros behave more like functions in other languages would. But looking at expl3 as a beginner while already having a lot of knowledge of the underlying engine, I do not truly believe that the new syntax will succeed in shielding off the underlying engine. The problem is that if it fails to do that then it is not a replacement language, but an additional language that needs to be learned and used on top of the already existing macro language. And, at least to me, it is an additional language with very unfamiliar syntax and semantics.
All in all, I much prefer traditional TeX style macros with lua for more complex tasks.
(Note: the answer covers things that were in various versions of the question!)
The question asks about two main issues, the 'primitives renamed' idea and the 'argument specification'. Just as background, the
On 'primitives renamed', in the main directly using the primitives is not the idea of the
was given. To put things on a more concrete footing, the current
The idea is, however, that the primitives should not really be used in most cases (outside of the kernel itself). So instead the recommended test would be
for two branches or
for a single branch. I've argued that the documentation shouldn't even mention the 'renamed primitives' where there is a better alternative.
On the 'argument specification' idea, I should first say what it is. The idea of the
where the name is the same but the arguments are different. So the idea is that I can read the above an quickly see what the test is supposed to achieve.
The second part of the 'argument specification' idea is that it allows a systematic way to show expansion. An example is
but it is hard to extend this to all of the possibilities. The same idea in
I can then go further, as
Obviously there are more example that can be given for this, but that is best studied in something like 'expl3.pdf' or recent TUGBoat articles I've written.
The question asked if the community likes these ideas. On that, I can offer no real answer other than a personal perspective. There is of course a learning curve to the syntax, and that will put some people off. However, I think that it does address at least some of the issues with writing code in TeX.
The question also asked about the downsides. One obvious issue is that
There is also the point that
(LuaTeX offers the possibility to program in Lua, which is obviously an alternative approach to
When writing expl3 code, whitespace is ignored. This produces more readable code because you don't have comment chars littering the ends of most lines. Consider
It might not seem much, but it takes away the cognitive burden of dealing with whitespace problems. You can change your indentation/brace style without worrying if you need to add
By the way, if you need to insert a space in expl3 code, you use the ~ char instead, which has catcode 10 for this purpose.
One of the fundamental improvements of the expl3 syntax revolves around its use of argument specifiers; that is, what comes after the : in the function names.
These argument specifiers signify how the arguments to a function will be pre-processed before being executed upon. For example, TeX provides the \let primitive to copy the meaning of one control sequence to another.
In expl3, this is written as
The "N" means an argument of a single token, and \cs_set_eq:NN in this case is the base function from which variants are created. For example, this is equivalent to the above:
What the "cc" is saying is that before being executing \cs_set_eq:NN, first take the two arguments and turn them into control sequences. Other variants in this case are :cN and :Nc. To write this in TeX syntax would be
I hope you'll agree the expl3 version is more readable and maintainable.
Another argument specifier is "V", whose meaning is "take the next token and replace it with the data stored by that token". For example,
The "V" arg spec works not only with token list variables (or macros) as above, but also with token registers, integers, and so on.
Now, it happens that \cs_set_eq:VN isn't defined out of the box in expl3. No problem, there is a generic method for creating new variants:
In brief, the full list of specifiers are
The "T" and "F" specifiers don't do any expansion; they exist solely as a shorthand to signify true and false branches of a conditional. Please read the expl3 docs for more information.
While other programming tools for LaTeX convey similar ideas, the advantage in my eyes to expl3's approach is the generic and extensibility of the argument specifier syntax. Your package has a command that takes nine arguments? No problem at all to write
Obviously ridiculous, but in practise very powerful and convenient.
(Answering the question as revised.)
TeX does not provide any namespacing, and so there is only convention to keep the macros/variables of one package separate from another. Knuth introduced the idea of using an extra 'letter' in the plain TeX format, where he used
but there is no reason not to simply use
from a purely technical point of view.
The choice of
One clear issue with using
I see two potential problems with
Of course, LaTeX 2e doesn't do so well with that last point either.
The changes to
The second potential problem is debugging. As we all know, debugging LaTeX is painful. Often, the best way is to use TeX's tracing ability and see what it is actually doing. Consider the following if statement.
It's a very simple piece of TeX code and if we look at the tracing output, that is reflected.
(The false branch is similar except it says
Now consider the corresponding piece of expl3.
Apart from the
I'm trying to imagine what this would look like for a complicated piece of code. The most confusing part is this could have been written very simply as
Of course, it could be that it's just so much easier to write readable code that no one will ever have to look at TeX's execution.
Either way, I'm looking forward to seeing what LaTeX3 has to offer.
I've done a couple of Google searches.