Multiple Language Support

[Marc Wachowitz]

Fare Rideau <rideau@ens.fr> wrote:
> > I'd say the only reasonable _high_level_ approach [...]
> > is to have a procedural interface to abstract data types [...]
> Not sure what you mean.

I mean that instead of accessing internals of some complicated structured
object directly (nested list, hashtable, vector, structure, etc.), one
would have to treat the respective type as an abstractly typed object,
performing any access through accessor/modifier procedures. Then only the
signatures of those procedures need to be statically and/or dynamically
typed according to the respective programming language. (Of course, it may
still be possible to generate inline access code for simple cases; I'm only
talking about "as if" semantics).

> You mean that, for instance,
> that LISP functions that want to talk to ML functions
> should explicitly construct/destruct ML objects through ADT interfaces,
> and (hence) that ML could only use Lisp through explicit stubs?

There shouldn't be much need to do such direct interaction; that's the
point of building abstractions which are usable from different languages.
What's really required to make them interact reasonably well would only
[need to] be known to the compiler. Since e.g. ML would be compiled to
Common Lisp, one could probably generate code without too much extra work
beyond what the front end of a ML compiler would do, and let the generated
idiomatic Lisp code for interfaces be optimized mostly by compiler-macros.

> the possibility to declare (and verify) conformance of Lisp code
> to invariants required by ML code.

For some cases, this might be possible even within the limits of the Common
Lisp type forms - though I wouldn't necessarily expect a typical Common Lisp
compiler to work very well on the kinds of types one would get from ML. If
the additional needs for ML (you'd have to ask an ML expert what this would
be) aren't too difficult to put into Common Lisp's type system (and into the
implementation, i.e. CMU-CL), extending type forms be a workable strategy.

> It seems that the major sources of problems for Scheme and CL to interact are
> * #f '() 'nil distinction
> * call/cc
> How much would it cost to have CL programs
> recognize 3 different internal representations for NIL ?

I'd expect most list-end-checks would still be acceptable, assuming a clever
encoding of those types (such that you'd only need very simple masking of an
immediate value), but general EQ comparisons (which are often used exactly
where performance is needed) would be slowed down on many architectures.

However, the more serious problem is the other way around: What should Scheme
do with something when it doesn't know whether it's NIL, #f or ()? Having each
of symbol?, null? and boolean? be true (and be false for IF etc.) for Common
Lisp's NIL would introduce an "interesting" source of bugs for existing Scheme
software. Personally, I'd not want to maintain a large amount of code which
potentially had such problems.

> > 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.
> >
> Yup. Could CMUCL be made to support it?
> * for uniquely called continuations, which is the main use?

If you mean escape-procedures, it's trivial. If you mean something more
complicated, which merely happens to call some continuations only once,
I'm not sure whether you can do it much better than the general case.

> * for duplicable continuations?

I don't know the internals of CMU-CL at all (I don't even have them here,
only the executable). However, I'd expect that if thread support is added on
a relatively low level, it should be possible to translate Scheme code in
a way which would allow continuations to work correctly, though perhaps not
very efficiently in the most general case. If all else fails, some form of
CPS compilation could be used even for vanilla Common Lisp as target (it may
cost some performance, though, in case the Common Lisp optimizer doesn't do
considerable inter-procedural-analysis and register allocation; I didn't try
what CMU-CL would do with such code).

> > A few projects trying to integrate semantics of Prolog and Lisp
> Are you thinking about Poplog, or about something else?

I'm not thinking of any specific implementation; this is just from (poor)
memory about various research reports on the topic which I've read over the
years (I don't remember any particular references).

>[Defining APIs for extra functionality over ANSI Common Lisp]

Btw, a few days ago, I started reading the Common Lisp HyperSpec from the
beginning to the end (something I recommend to everyone who wants to design
a Lisp/Scheme system - it's quite impressive of what these people thought),
and noticed that CMU-CL doesn't implement e.g. DEFINE-SYMBOL-MACRO yet. IMO,
we should make CMU-CL implement the ANSI standard completely - it would be
embarrassing to have a LispOS, but not even a conforming implementation ;-)

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