Re: [Texmacs-dev] Multiple extension languages II (Caml, Python, Lisp, etc.)

[Joris van der Hoeven]

On Wed, 12 May 2004, David MENTRE wrote:
> I agree that it would be nice to have several extension languages. I
> agree with your idea of remote objects and computations, as well as
> local variable for remote computations.  However this does not solve the
> distributed garbage collector issue completely: what happens when a
> scheme function that uses remote variables is returned to a scheme
> caller?

This cannot happen. Mixtures of remote-local objects
are considered to be remote (with an id, etc.).

If you transform a remote object into a local object
(via pretty printing + parsing over a pipe, for instance),
then the result should not contain any remote objects any more,
even indirectly.

> I have a question : in current texmacs, how is used Scheme? How is it
> tied to the core of TeXmacs in C++?

Look at the src/Guile/Glue directory.

> Maybe having remote objects is too complicated at first. Why not just
> consider function calls with argument copying semantic? Much like Remote
> Procedure Call (RPC) over a network. I admit it is overkill for simple
> functions, but it is much simpler. No garbage collector issue.

That is fine with me too. This is simpler from the garbage collection
point of view. However, one needs a protocol for each data type one
wants to transfer (in the remote object context, there is no need
for this since objects are black boxes).

> If one wants to interface several languages, the C++ core could be used
> as storage (e.g. OCaml<->C++ core<->Scheme).

That is a minor issue. We may store information at the Scheme or
the C++ level, or even at a third party plug-in.

> It would also be interesting to define the spec of the sub-system to
> have other languages:
>
>  - how to tie the language interpreter to texmacs?

TeXmacs supports virtually all possible methods now: pipes, dynamic
libraries and sockets. It is probably best to keep our mechanism as
independent as possible on the way communication between TeXmacs and
the extern language plug-in takes place.

>  - how to publish to texmacs function callable into the new language?
>    If I have understood correctly, constructive first order logic is
>    your solution to this issue.

First order logic is rather used for typing. But in order to start
we may stick to communicating simple atomic types only, as well as
routines on such types.

>  - what is the encoding format for function call and value return?

It should be possible to specify this dynamically. At the beginning,
we might only require that all communication takes place using string
streams (so as to keep the system as independent as possible from
the means of communication: pipes, sockets, etc.; we should first
focus on functionality, next on efficiency). In other words,
for each type, you need to specify a method for serializing and
parsing objects of this type.

> > Someone wants to come up with a more precise proposal?
>
> Sorry, I cannot commit to do this in the short term (despite I have
> triggered this discussion). I'm currently piling up to many projects. In
> the long term, I would be interested in maintaining the Axiom plugin
> and interfacing OCaml with texmacs.

What is in the long term? I do not think that a first implementation
would take that much time (a few weeks?). It would surely be very
interesting and trigger the development of better plug-ins for
many extension languages (Caml, Lisp, Python, Perl, etc.) and
maybe even for some computer algebra systems.