OS/S1 and LISP and others

[FTP:GLS at MIT-MC (Guy L. Steele, Jr.)]

It occurs to me that a highly desirable characteristic of an operating
system would be that maximal attention is paid to allowing routines
written in various languages to call each other freely.  This can
pose several problems for language implementations which either
have extensive run-time support systems or are interactive and so
must support dynamic interaction.  LISP falls into both categories.

To see the problem with clashing run-time systems, consider the PDP-10
UUO feature, and trying to get FORTRAN and LISP to coexist.

As for dynamic interaction, LISP in principle allows the user to
call for the invocation of any extant function in the system.
MacLISP supports this by providing its own idiosyncratic run-time
linking loader.  Much as I hate to admit it, Multics did have somewhat
the right idea here, allowing nearly any function to invoke any other.
In order to do this, the system has to have linking
and uuo-handler type support within it.  Also, being able to
write procedures which are callable both from "command level" and
from programs is a good idea in principle, though the particular
arrangement in Multics (different syntaxes for the two cases)
made it difficult to exploit this thoroughly.  LISP of course does
this all the time within its world, but it would be nice to have it
work among all languages.

To prevent run-time systems from clashing, I thinm one
must avoid "fixed" resources.  For example, with I/O
channels, one needs to be able to say "cons me up a channel and
tell me which one" a la Tenex JFN's, rather than only "open channel 4".
(The horrid word "capability" springs to mind here.  Sigh.
But this notion allows one to think of "consing up" fresh objects
and then passing them around from procedure to precedure.)

One also needs some interfacing standards for procedures which are
both flexible and efficient.  See VAX documentation for
an effprt at this which is not a complete loser (though it almost is).
The idea of the CALL instruction pushing a random zero word bites the
bag for a number of reasons,, and the arg pointer/frame pointer
mechanism may be too restrictive for LISP (though it will
probably be enough for PL/I and PASCAL and FORTRAN); but at least
they tried.  The "standard data formats" for argument transmission
are not a total loss either, I guess.

Any kind of dynamic linking feature must be flexible enough to
support linking not only of code but also of data.  When a new
procedure is linked into an existing group of LISP routines,
one needs to be able to identify certain atomic symbols,
list structures, etc. for use by the new routine.
These are language-specific, so maybe each
"segment" needs an intiialization routine that gets run when
the segment is linked in.


// 38 //