More on common language runtimes

Ian Bicking from comments...

You mean, tried it like Guile? That was the whole premise of Guile, that you could translate other languages into Scheme. They never even got as far as translating elisp (which should have been the easy part) so that they could move Emacs to Scheme. That might not really be fair -- honestly, I don't know if anyone cared enough to try, Guile was born of a flame and never had a real champion...

I did not know that was a goal. I've neither tried Guile nor even looked at it. Sounds like more of an organizational thing than a technical issue. The history of Lisp is full of people writing compatibilities to move their code from one (usually older) Lisp system to another. This ultimately led to Common Lisp to avoid doing this so much.

Someone also tried translating Python to PLT Scheme, and they ended up giving up and just embedding Python in the Scheme interpreter...

Guile was crappy to debug Scheme in, but it offered absolutely nothing for any other language built on top of it. Can you annotate your Scheme source with information that allows you to reconstruct the native language environment when there's an error? Many languages deal poorly with incorrect programs, but Scheme implementations tend to be particularly bad, as is any implementation that comes out of an academic background (rather than being designed by a programmer that actually wants to *do* things with their implementation).

Gambit is a good choice because of its C interface, compiler to C, and good debugging capability. Again I am shooting from the hip, but for annotating Scheme source with information for reconstructing the source language information, the nice thing about this is it is Scheme and you can define all kinds of "meta-data" that does something or does nothing execution-wise, but just keeps information around (or eliminates it when desired). Everything is a list, remember. 8^) Just define syntax and/or structure that keeps the information you want, e.g. source text spans for highlighting an expression in a debugger or whatever. Seriously for non-Lisp programmers: everything is not a list. Scheme has "records" ("structs" in C), objects, vectors, etc. I would try defining records for the "meta-data" and the Scheme code would include references to these records.

And that doesn't even deal with the object mismatch issues. You don't actually have to resolve those issues if you just want to take advantage of the performance of the underlying implementation, but if you want to leverage it for interlanguage communication, translating it all to Scheme doesn't actually accomplish a whole lot.

I personally would not want to try reconciling object models too much. I would have each language keep its own definitions and see how easily the translation to Scheme data can support those languages. I would define some kind of interchange but that would not have to be too elaborate. Maybe start with YAML and leave it at that.

I'm highly sceptical of any academic projects, as I they tend to be mismotivated.

Yes, this is just a thought experiment for me. Like the Python and PLT Scheme observation, it may simply be unnecessary when the original language implementations can simply communicate with each other well enough.

The one time I could see attempting something like this would be when defining a new language from scratch. Lisp has always been a good vehicle for experimenting with new languages. They've tended to be more academic and less production too, but something like Gambit for performance is intriguing.