🚀 go-pugleaf

In article <39odfp$nvq@love.loyola.edu> bkuhn@justice.loyola.edu
(Bradley M. Kuhn) writes: 

   In article <398tet$9lp@csnews.cs.Colorado.EDU>,
   Tom Christiansen  <tchrist@mox.perl.com> wrote:

   > A significant challenge will be for the
   >FSF to implement this great extension language and then provide a generic
   >API so that people building things don't HAVE to use it, so that they
   >could in fact, if they desired, used tcl or ksh or rexx or whatever.  If
   >they don't do that, then it does seem to me that they've fallen into the
   >same ticklish trap that rms was complaining about: taking away choice by
   >locking in the extension language to the app.

   This is a good point.  However, how would this work?  It sounds as if Tom is
   propsing that the generic API go through C (or some lower level like that)
   rather then through the Scheme-like CL that GNU is proposing people write
   translators for to use their favorite extension langauge.

Actually Tom's idea (if I understand it correctly now(!)) is far more
fundamental than this and potentially far more exciting as well.

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.  (Which of course means that
applications have to listen for events from the interpreter in the
same way as they listen for events from the X server.)

Thus individual applications do not have to include any interpreter
code themselves, just a small library to communicate with the
interpreter process.  And the resulting functionality has enormous
potential!

I imagine that Tom will correct me if I have misrepresented his idea!

The way *I* see it is that GEL as proposed will be a very good thing
anyway, and then someone will write the IPC library and modifications
to GEL that allow it to run in the way Tom would like.  So hopefully
we will end up with the best of all worlds and a significantly
powerful system.

	Neil.

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