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

[Joris van der Hoeven]

Some further details on the last part of my previous message.
To fix ideas, assume that we want to use Caml as a second extension
language.

> I think that it would be best to keep the protocol as simple as
possible.
> Basically, we should implement:
>   1) extern functions and objects (both in Scheme and the new language).
>   2) communication of signatures (lists of symbols and types).
>   3) communication of objects of the "same" types in distinct languages.
> Any comments on how to do this in more detail?

--- 1 ----
We need a type for "extern objects" both in Scheme and in Caml
(in Scheme it only needs to be implemented once; the type can
be reused for Python etc.). The idea is that an extern object
is referenced by a unique identifier which enables us to find
the instance of the plug-in where the object is actually stored,
and the object itself. Extern objects may either be routines or data.

When calling an extern routine with extern data, the idea is to
remotedly apply the extern routine to the extern data,
which creates a remote object. We next create a new identifier
for this object and return it to the caller which creates
a new extern object with this identifier.

--- 3 ---
Sometimes, we may wish to physically transfer the result of
a remote computation and not merely its unique identifier.
In that case, depending on the type of the object,
both Scheme and Caml should provide a way to pretty print
the object and to parse it.

Notice that 1+3 induces the complicated problem of distributed
garbage collection. In general it is probably a bad idea to
persistently store remote objects (unless explicitly needed),
since they will be hard to collect. Often, one rather wants
to perform well-identified parts of a computation remotedly
and retrieve the result as a local object (modulo a conversion).
For this purpose, we may use a keyword "let-remote" like in

(let-remote (x y z) ; new remote variables
  (set! x (remote-func ...))
  (set! y (remote-func x ...))
  (other computations...)
  (set! x (remote-func y ...))
  (set! z (remote-func x y ...))
  (convert (remote-func x y z ...)))

The idea here is to destroy the remote objects x, y and z
after the computation.

--- 2 ---
I propose to use general constructive first order logic for
typing interfaces (like in Mathemagix). In fact, we will only
use part of it, but at least we will be sure that we won't
miss anything and that arbitrarily complex objects can
(theoretically) be typed. For instance, a signature might
be something like the following list

        (+ (-> Int Int Int))
        (append (forall T (-> (List T) (List T) (List T))))
        (cursor-go-to (-> Path Void))

Probably, it will also be convenient to have a simple module system
for regrouping lists of signatures. For instance:

        (module cursor-facilities
          (cursor-go-to (-> Path Void))
          (cursor-go-to-eol (-> Void))
          ...)

In the future, such a module system may also do some renaming
depending on versions.

In relation to 2), a module may in particular export conversion
functions. These may be converters from Scheme, Caml, etc. to
some universal common format (i.e. using pretty printing and parsing),
or more direct converters. I.e. (using :: for module scoping)

        (module tm-caml
          (converter (-> String (:: Common String))) ; pretty-printer
          (converter (-> (:: Common String) String)) ; parser
          (converter (-> String (:: tm-scheme String)))
          ...)

Any suggestions?
Someone wants to come up with a more precise proposal?