On 14 April 2011 01:23, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> In general, there may be a need for a very good lisp virtual machine to
> run and integrate lisp code in general (CL, various schemes, and other
> sorts of lisp-like languages, we could include perhaps implementations
> of python, ruby, smalltalk, javascript, etc). From well afar, it
> looks like the JVM is not good enough for lisp (ABCL, Clojure, seem to
> have some difficulties to implement some basic lisp features on the
> JVM).
The problem of language integration has become common enough that we
already have the opportunity to make some observations about what did
work, and what didn't. A concerted approach to working with distinct
object spaces / models would be a mammoth task, it is entirely a
different undertaking to integrating two particular languages.
The particular issue I find is that the mechanisms for defining how
two object spaces interact don't compose well. If you work in a Java
environment, for example, you may know how to interact with or create
Java objects from JRuby, Kawa, Jython, E and Clojure, but that doesn't
let you interact between any of these languages in a sane way. Quick,
what is the process for reifying my Jython or Kawa function as a
callable in JRuby?
This common-denominator approach applies equally well outside these
safe bytecode VM environments - there are all sorts of mechanisms for
generating FFI code for specific VMs given a C or C++ interface. For
the most part, they make you feel like you are writing C or C++.
Another thing worth thinking about involves promoting idiomatic usage
despite differences in languages. If you've ever implemented a
language inside a VM that was not designed for it, you will know what
I mean when I ask questions like:
0. Objects in javascript are maps from string keys to any value. If
they are to be cast as hashes or dictionaries when passed to a
language that allows non-string keys, and the language adds a
non-string key, what happens to the javascript object?
1. How are "other" languages to make or handle multi-valued returns?
2. What happens to cons cells at the boundary between languages where
one has immutable cons cells, the other mutable?
3. Further, what happens when a language with linked lists as the
default sequence type and one with arrays as the default sequence type
interact? Consider, for example, the various options that pymacs
provides.
4. What about operators, and the various mechanisms and naming
conventions, single/multiple dispatch, AND the guarantees provided by
each operator mechanism in any given language?
5. What do you want to do about subclassing and multiple inheritance?
In a single-inheritance language like Java, the compiler is free to
assume that in
if (x instanceof Foo) { }
if (x instanceof Bar) { }
that if Bar and Foo are distinct concrete classes, and one is not a
subclass of the other, the second if can be replaced with an else if.
Method resolution order is not consistent between MI languages,
either, and may be further complicated by how they are to interact
with generic functions.
6. Languages may also make type-related requirements that need to be
checked somehow; such as some languages not permitting the initialiser
to be called more than once, final methods, &c.
7. In what way to generic functions and methods interact? How about
classes and typeclasses?
8. What happens when a language that is strict about arity interacts
with a language that does not? Does calling a javascript function
from python with the wrong number of arguments raise a TypeError, or
silently pass undefined? Does the inverse pass None?
9. Do the error handling and exception mechanisms intersect - say,
what Java exception does my Elisp args-out-of-range become? Exception
hierarchies can be *very* different across object spaces.
10. How do methods overloaded on static type look from a dynamic
language? Oh, and what about virtual/non-virtual methods and extension
methods as on ecma CLI?
I'm not saying that these questions don't have answers, but I am
saying that in order for the abstraction to compose well, there needs
to be a way to express the solutions to problems like these, and
preferably, a way to drop down to a lower level and specify a
different behaviour. This is by no means a complete list (although as
you can probably see, it's a problem I've meditated on regularly),
just a taste.
However: Guile was *designed* to be a multi-language VM, and has a far
nicer object model and MOP than something like the JVM or CLI. If
scheme were the common denominator, it might be so much nicer than
what we've seen before that the jarring that comes from crossing
several object space boundaries is not as severe. I just mean to be
careful about whether you are suggesting moving to a single VM,
implementing an automated FFI tool with several backends, or solving
this problem generally, because they are each projects of very
different scale.
--
William Leslie
