🚀 go-pugleaf

In article <NJ104.94Nov9121749@hilsa.amtp.cam.ac.uk>, nj104@amtp.cam.ac.uk (Neil Jerram) wrote:
>He thinks that any extension language interpreters should run sort of
>as daemon processes separate from the main application process.  The
>`source' application notifies the interpreter by IPC of the primitive
>functions that it provides.  Any application (including the `source'
>application) can contact the interpreter to ask it to run a script
>(written in some extension language) that uses the primitive functions
>provided by the source application.

>Note: IPC = inter-process communication.  What is API?

API = Application Programming Interface.

The interpreter does not necessarily have to run as a separate process;
it could be linked in (although obviously an interpreter packaged as a
dynamic link library would be more flexible than one statically linked
into the application).

Let's take a look at my favourite extension language, for example. :-)  It
already has an API which seems to fit the requirements of this discussion.
An application that wants to use this language as an extension language
provides any or all of the following.

  * Command interpreters.  Not as in GEL but as in the bit of dbx that looks
    at the command "print a+b" that you typed on the input line and executes
    it, or the bit of emacs that looks at the command "goto-line: 35" that
    you typed after pressing M-x and executes it.
  * Function evaluators.  These take in string arguments and spit out
    string results (in suitable packaging).
  * Exit handlers.  These interrupt the language interpreter at pre-defined
    points in order to handle such events as terminal I/O in a customised
    way.

The application registers the command interpreter(s), function evaluator(s)
and exit handler(s) under names that it chooses, by calling functions which
the language interpreter has exported:

RexxRegisterSubcomExe(PSZ envname,RexxSubcomHandler *handler,PUCHAR userarea);
RexxRegisterFunctionExe(PSZ funcname, RexxFunctionHandler *handler);
RexxRegisterExitExe(PSZ name, RexxExitHandler *handler, PUCHAR userarea);

When a program in the extension language is started it will be able to send
commands to the application with the instruction

  address envname "a command to be sent to the application"

where envname is the name under which the application chose to register the
command interpreter.  The program will also be able to call functions from
the application using an ordinary function call:

  answer = funcname(arguments)

where funcname is the name under which the application chose to register the
function evaluator.

The application may start the interpreter using another function that the
interpreter exports to the application:

RexxStart(long argc,PRXSTRING argv,PSZ *name,PRXSTRING instore,PSZ envname,
          long calltype,PRXSYSEXIT exits,PSHORT rc,PRXSTRING result);

The interpreter starts up, runs the requested program (which is supplied
either as a file name for the interpreter to read from disk or as a string
of instructions in memory) and then finally terminates, possibly returning a
result string to the application.

Most existing Rexx applications and interpreters run in a single thread
of execution with control being either in the interpreter or in the
application at any one time.  But there is nothing to stop an implementor
from implementing the above function calls using RPC to another process.

Ian Collier - Departmental Lecturer (and perpetual postgrad student) -
imc@comlab.ox.ac.uk - Oxford University Computing Laboratory, Wolfson
Building, Parks Road, Oxford OX1 3QD - WWW Home Page:
http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html