[Dev-luatex] Q: Why does LuaTeX embed rather than extend?

Hans Hagen pragma at wxs.nl
Fri Jul 4 22:30:33 CEST 2008

Jonathan Fine wrote:
> Hello Hans
>> maybe in 2016 we have reached a point that many aspects of tex have 
>> been rewritten in more independent c modules that then are glued 
>> together by lua but it does not change the principle ... it's still 
>> 90% tex then
> Hans, are you saying here that extend would be better, were it not so 
> much work?  Or are you saying something else?  I'm not sure.

well, we're are quite content with tex as it is but decided it was time 
to open it up and use lua for that purpose (with the added benefit of a 
scripting language that can be used for other purposes); there' snothing 
wrong with tex as it is apart from some things that we wanted to add to 
it for a long time and the fact that it had to go open type, unicode etc 

our choices are such that no solutions are implemented (this saves much 
useless discussions that due to conflicting opinions would lead to 
nothing) but only mechanisms for users (macro package writers) to add 
functionality to tex; the basic building blocks remain

>> also, our choice for lua, as well as the decisions we make are driven 
>> by  respect for tex (as it is), lua as it is, the things that the 
>> three of us have wanted to see in tex for ages and of course fun
> My question is not about your choice of Lua, but the decision to embed 
> rather than extend.  As I already mentioned, the socket module extends Lua.

we use lua as it is meant ... as an extension language

sockets are a general purpose library which is quite something different 
from tex

> Here's another example.  LuaSQL is an extension of Lua that allows "a 
> Lua program to connect to ODBC, ADO, Oracle ... databases" and perform 
> database operations.
>     http://www.keplerproject.org/luasql/index.html
> LuaSQl is C source that can be compiled to generate a library that can 
> be linked to the application or dynamically loaded.
>     http://www.keplerproject.org/luasql/manual.html#compiling
> Providing a typesetting extension to Lua would similarly allow any Lua 
> program to connect to the typesetting engine and perform typesetting 
> operations.

of the reverse, one can extend luatex to load extra libraries

luatex is the core application; just as games that use lua are core 
applications, and just as adobe does not extend lua with imagine libs 
but provides an application that uses lua; take fontforge ... it uses 
python as extension language and remains the core app

> [discussion of documentation snipped]
>> well, that would be true for all games that use lua, editors, adobe 
>> progs etc ... it makes no sense to link all of them together ... you 
>> miss the whole point lua
> I think it makes perfect sense to link an editor and a typesetting 
> engine together.  And someone writing a 'Learn Mathematics' game might 
> wish to connect to a typesetting engine.

as said, maybe in 2016 we have redone so much that one can think of 
luatex as a collection of libs, but even then a user needs the 
application luatex for it to be useful in itself

also, we want a stable and well defined next generation tex, which means 
that luatex has all the libs that we decide to make sense built in (and 
maintained in the source tree); also, on top of luatex one uses macro 
packages; luatex in itself is not that useful

(btw, if one thinks of lua as a huge collection of libs, then it becomes 
like perl, python, ruby etc ... big bigger biggest and we enter 
maintainance, compatibility, distribution etc problems ... again a 
reason why we used lua as an *extension* language.. small is beautiful)


                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl

More information about the dev-luatex mailing list