Recently something has happened to TeX that should change the way we
are thinking. This is the fact that LuaTeX has reached Version 0.50.
In theory, only people living on the bleeding edge use LuaTeX. There
is a warning in the Reference Manual:
Nothing is considered stable just yet. This manual therefore simply
reflects the current state of the executable. Absolutely nothing on
the following pages is set in stone. When the need arises, anything
can (and will) be changed without prior notice.
In practice, the bare necessities are not likely to change after 0.50.
I refer to the TeX command \directlua and the Lua function tex.print.
\directlua takes one argument, a Lua script, which is executed
immediately.
tex.print takes one argument, a string, which is passed to TeX.
The net effect is that the command \directlua{...} acts much like a TeX
macro.
Lua is a minimalist programming language: simple syntax, only eight
types (of which the casual user needs six: nil, boolean, number, string,
table, function), and 21 reserved words. All arithmetic is in IEEE
double precision. It has a string library with powerful pattern-matching
capability. It is just the sort of language that can easily translate
PMX-style notes into MusiXTeX macros, computing note and line spacing
as it goes along.
LuaTeX gives access to all the power of Lua from inside a TeX document.
Currently an M-Tx user relies on:
- A preprocessor written in Pascal, compiled to be a stand-alone
executable, which is different for every operating system
- PMX, which is written in Fortran, compiled etc, different etc
- musixflx, which is written in C, compiled etc, different etc
I have on two occasions asked on this list whether anybody wants to
help me convert M-Tx to Python. Christian Mondrup convinced me that
we shouldn't, as outside the Unix world people don't already have Python
anyway.
The objection does not apply to LuaTeX. All recent TeX distributions
have it, maybe at this stage only as an optional extra, but it is being
billed as the "next generation TeX engine".
If we had LuaTex in 1992, musixflx could have been implemented in Lua
and there would be only one TeX pass.
If we had LuaTeX in 1996, PMX could have been implemented in Lua and
there would not have been pmxa and pmxb passes.
If we had LuaTeX in 1999, M-Tx could have been implemented in Lua and
there would not have been a prepmx pass.
Now it is 2010 and we do have LuaTeX.
We can go on as we used to: regard musixflx as cast in concrete, rely
on Don to keep maintaining PMX (nobody else except me, as far as I know,
has contributed even one line of Fortran code to it) and hope that someone
occasionally tweaks M-Tx to take account of some recent PMX feature (that
person is no longer me).
Or we can gradually convert more and more of the functionality of these
packages into LuaTeX, thus taking advantage of the fact that the next
generation of TeX package writers will be fluent in it and will be able
to maintain the software. A single package luamusix.sty will do everything.
I think the choice is obvious. Don't you?
Dirk
PS If you would like to try LuaTeX for yourself, and find the official
documentation a little daunting, you may like to read the story at
http://dip.sun.ac.za/~laurie/luatex
-------------------------------
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to
http://tug.org/mailman/listinfo/tex-music
