Multiple Language Support

[Fare Rideau]

>>: Fare Rideau <rideau@ens.fr>
>: Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>

>> 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,
Good point. Noone wants that.

> I'd say the only reasonable _high_level_ approach [...]
> is to have a procedural interface to abstract data types [...]
Not sure what you mean. 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?
Well, that sure should be the general idea at some point.
   However, I'd like that some meta-programming be used to automatically
generate/inline/remove those ADT/stub interfaces where applicable;
hence, the possibility to declare (and verify) conformance of Lisp code
to invariants required by ML code.

> and (implicit) low-level compatibility for a few simple and frequently
> used data structures.
Sure.

>[Use Common LISP]
Well, I think we all agreed about that, at least to begin with.
However, I don't forget my objective of building
some kind of Reflective Language with Invariants,
that would be used as a simpler extensible system,
to implement the layers below CommonLISP,
as well as the foreign-function-interface.
Plus there's a lot of Scheme code to recycle, too.

>[Scheme-in-CL]
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 ?

> 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?
* for duplicable continuations?

> 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).
>
Mmm. I'd like to see such a beast, all the more if the compiler is
to remove run-time Lisp-to-ML type-checks
(which would allow better code sharing between ML and Lisp).

> 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).
>
Are you thinking about Poplog, or about something else?

> 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.
>
Yes.

>[Defining APIs for extra functionality over ANSI Common Lisp]
Yup. It will also give a precise goal for lower-level hackers to implement.

#f