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 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 ----------------------------------------------------------------- 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 -----------------------------------------------------------------