[Dev-luatex] REQ: Please tell comp.text.tex why LuaTeX chose embed rather than extend.

Jonathan Fine jfine at pytex.org
Mon May 25 12:26:20 CEST 2009

Hans Hagen wrote:

>> In Python I can write
>>   import pyscopg
>> and then I have a module that allows me to connect to a Postgres 
>> database, and add, change and delete records.  In other words I have 
>> imported into Python a database extension.
> connect ... so the database itself runs indepently (and has a 
> comunication channel to a certain amount of clients)

Yes, Hans.  Pyscopg is a Python extension (probably written in C) that
can be imported as a module and which allows a Python script to connect
to a database (via a database server, of course).

>> But all this is a little off the topic of embed and extend.  Postgres 
>> can embed Python, and one can extend Python using Postgres.  This is 
>> the dual example, and it helps show us what embed is good for, and 
>> what extend is good for.
> so, in your example its not even embedded or extended that we're talking 
> of but connecting; 

No, Hans, and my apologies for not being sufficiently clear in my
previous post.
1.  Pyscopg is a Python extension.
2.  Postgres has an API that allows it to be used as a service.
3.  Pysocpg is a Python extension that can connect to a Postgres database.

So it is 'extending Python (with a connection to a database)'.

> well, it is no secret that luatex provides sockets so 
> you can start a luatex session, connect to it, send some text, and get 
> back whatever you want, in the sense that you can serialize for instance 
> a node list, (which in itself is not that useful as it lacks resources)

Yes, I agree.  One can write Lua code that would allow LuaTeX to
function as a server, and some additional work would be required to make
that service useful.  Or, because the C-libraries (used also by Lua)
support sockets, one could write an extension of TeX that functions as a
server.  Each approach has its advantages and problems.

To return the dual-example provided by Postgres.   I could, as you
suggest, write Lua code that allows LuaTeX to provide typesetting as a
service, via a socket interface.  Here, I would be using Lua as an
embedded language in the typesetting program.  It is akin to using a
"stored procedure" in a database program.

I could then wrap the API provided by LuaTeX (plus the code just
mentioned) in a module that could be imported, say, by Ruby.  This would
be an example of extending a dynamic language (with a connection to a
typesetting engine).


More information about the dev-luatex mailing list