Multiple Language Support

[Marc Wachowitz]

Fare Rideau <rideau@ens.fr> wrote:
> Just the ability to run programs in other languages does not mean
> *supporting* them.
[...]
> it means that the system can express, enforce and propagate the invariants
> required by the supported language in as automatized a way as possible.

Unless you want to bloat each of those languages into a super-language
which supports lots of stuff from other languages, I'd say the only
reasonable _high_level_ approach (you don't want to use too much low-
level bit-manipulation of a common data format, which is going to hurt
each player equally bad, right? ;-) is to have a procedural interface
to abstract data types (preferably with not-too-complicated object-
oriented interfaces, which should still be usable from non-oo languages),
and (implicit) low-level compatibility for a few simple and frequently
used data structures.

An efficient Common Lisp with a good foreign-code/data interface should
already provide most of the necessary functionality to implement this,
and unless we perform some "grand new kernel Lisp project" (doesn't seem
so yet, as far as I can tell), it's the only standard Lisp which does at
least have a considerable part of the required functionality, and provides
good support for _embedding_ (not just implementing) a variety of sub-
languages with minimal effort.

> Scheme-in-CL is
> more interesting, but then, how well does that existing Scheme-in-CL
> allow interaction between software written in Scheme and in CL?

I don't know any such beast for Scheme with distinct #f and (), which
is a relatively new requirement.

In Scheme, the symbol NIL, the empty list, and the false value need to
be distinct. In Common Lisp, they need to be EQ, and you can't usually
reduce it to only one of those roles - and even then, not automatically.
This would make sharing (not just interfacing at a few places) of data
structures between both somewhat difficult (particularly if you expect
good performance and want to use both sides as if they'd dominate the
system).

Unless you want just Scheme-emulation in Common Lisp (that's trivial),
the Common Lisp implementation would need to support something like
CALL-WITH-CURRENT-CONTINUATIONS; this shouldn't be too hard if you've
got low-level support for threads in the system anyway.

The remaining stuff shouldn't be too hard.

For ML, you'd have to hide the non-statically-typed aspects of Lisp data
behind some procedural interfaces to abstract data types. As far as that's
acceptable, I guess it could be embedded reasonably well in Common Lisp
(I'm no expert on ML, though).

A few projects trying to integrate semantics of Prolog and Lisp appear
to indicate that we could also take it at least much better than the
typical integration of foreign services into Prolog (integration of
some Prolog features into Lisp is even simpler).

"Ordinary" languages like Ada or C should be conceptually simple within
a powerful Common Lisp (low-level stuff and tasking would have to be
sufficiently similar to provide acceptable efficiency), but the system
library interfaces for such languages would probably appear somewhat
"unusual" to their users, and (particularly) a few C programmers would
be a bit surprised to find out how little their standard guarrantees
about low-level operations ;-) Well-educated Ada programmers might in
fact feel quite comfortable with a good "Ada in Lisp" system.

However, let's remember that making most of our nice ideas work in Lisp
is already a considerable task, so don't get too euphoric about such
"Lisp rules the world" dreams ;-)

If we can put something good together based on Common Lisp - preferably
in a way which allows most programs to run on any standard Common Lisp -
that will already be a great achievement. Defining clean interfaces to
whatever we need beyond ANSI Common Lisp should already take us forward
quite a bit on that path. Particularly, low-level details of specific
implementations should only show up where necessary, and be used mostly
as abstractions which could be implemented differently on other Common
Lisp implementations (including possibly using another implementation
for the whole of "LispOS", in case we want to go beyond some limitation
which is too hard to get around in the initial system, or port to some
potential future "virtual machine" of whatever flavour).

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>