Lambda the Ultimate

Given that there are more than enough votes to allow this JSR to get started, BEA will not choose to oppose. However we are very concerned about any attempts to alter the ECMASCRIPT work being done in ECMA right now in a manner that jeopardizes or marginalizes that effort, which is of critical importance to BEA. We encourage the spec lead to coordinate with the ECMA TC39/TG1 WG to make sure they are kept aligned. Failure to do so may cause us to vote NO at community review.

You can compile any language down to 8086 assembler code. When Intel released the 8086, did we witness convergence in the field of programming languages? :-)

What we're seeing is just Turing-completeness and a reasonable enough design so that translated code didn't suffer horrible performance penalties. This is all that's really necessary for all existing languages to target your platform.

This is actually a good thing for language diversity. If you're a language creator, you'll likely find it far easier to target these runtime environments than to generate assembly code, and you'll likely see far better performance from these runtimes (with their JIT compilation) than if you write your own interpretter.

But let's not read more into the CLR and JVM than is there. They're just targets for which your compiler can generate object code, as are X86 and PowerPC.

No, we are not even seeing that. This jcp will not include any changes to the vm, it will just propose new API's for exposing java objects to interpreters (out side the vm?), and an extension to web application package. Others have propesed extensions that would enable dynamic languanges to perform better on tht vm, but it looks like they will remain ignored.

http://www.cs.ucsb.edu/conferences/java99/slides/p4-oiwa.pdf http://www.ai.mit.edu/people/shivers/javaScheme.html

And rightly so. The various incompatibilities between versions of the VM pretty much kill the "write once run everywhere" mantra which was, to an extent, the motivation for its existence in the first place. If there was one thing the aforementioned Intel got right with their x86 family is guaranteed backward compatibility.

Whereas, when you target the JVM or CLR, those details don't exist, because the decisions are already made for you.

And you pay a price, as a PL designer, for those decisions. So, to my mind, the interesting question is: is it possible to achieve simple and straightforward PL interop without having to sacrifice the unique aspects of those PLs that made worth while to use them in the first place?

1) Can you explain what incompatibilities have to do with running different languages on the VM?

2) I hear some people say this, but I have yet to experience it myself. I've written code that I've personally ran on X different versions of Windows, MacOS, Linux, Irix, Solaris, HP-UX, and AIX. I won't say that there aren't incompatibilities somewhere, but my personal experience has been otherwise.

And you pay a price, as a PL designer, for those decisions.

To an extent. The fact that the JVM disallows arbitrary pointer arithmetic means that it can be hard to create an efficient version of a low-level abstraction you might need for your language. I'd like to see somebody design a "secure" virtual machine that can do otherwise. I have a feeling that's not going to happen, though. My bet is that vm vendors will eventually just build in the abstractions people ask for - continuations, etc...

So, to my mind, the interesting question is: is it possible to achieve simple and straightforward PL interop without having to sacrifice the unique aspects of those PLs that made worth while to use them in the first place?

I would say that it depends upon the languages you are trying to bridge and the expansiveness of the bridge you're trying to build.

For languages that are similar, it's possible to integrate them very tightly - That's what I do between C++ and Java with Jace, http://jace.reyelts.com/jace. As an example, you can write C++ code that looks like this:

try {
  String str( "http://www.google.com" );
  URL url( str );
  InputStream input( url );
  BufferedReader reader( InputStreamReader( input ) );


  while ( true ) {
    String line( reader.readLine() );
    if ( line.isNull() ) {
      break;
    }
    cout << line;
  }
}
catch( IOException& ioe ) {
  ioe.printStackTrace();
}

I'd say that the bridge is pretty elegant. On the other hand, I don't even try to bridge C++ templates.

In general, I think it's straightforward to bridge most languages, which is why just about every language has a C bridge. VMs cause us problems, almost totally because of security's sake - i.e. disallowing arbitrary pointer arithmetic and unsafe casts (i.e. int to object reference). These are features that are widely used to create efficient language implementations.

I personally find the JavaScheme paper very interesting. They propose that the VM support an additional unsafe instruction set, which can be used to implement the language runtime. They also suggest a social mechanism for ensuring that people can determine which language runtimes are safely implemented.

Thanks for the links Ben.

Unfortunately I have. We've experienced problems with signed applets running on various browsers, OSs and VM versions. I've seen Swing code that works fine on JDK 1.3.1 freezing on JDK 1.4 . I've not personally written this code, so I can't testify as to it's overall correctness, but it's quit obvious that it happens, and that it can be a big problem.

Can you explain what incompatibilities have to do with running different languages on the VM?

Nothing directly, only that if you need to change stuff in the VM in order to get the interop you want, you may end up with the aforementioned incompatibilities between older versions of the VM and the new one.

That's what I do between C++ and Java with Jace

Looks very interesting. We currently use JNI to invoke legacy C++ code from Java apps. Has the advantage of being supported on most every system (we target Windows, Linux, Solaris, HP-UX, AIX and OpenVMS and may also target OS/400 and others in the future). Can't say I like it much (though I've created some C++ wrapper classes to ease the pain).

In general, I think it's straightforward to bridge most languages, which is why just about every language has a C bridge.

C represents a low common denominator, sort of a portable assembly language. This is why I don't think it's a sufficient yard-stick to measure multi-PL support and interop on VMs. Consider all the limitations of the JVM and the CLR in supporting dynamic languages, which have been discussed here often. Consider Mondrian, the functional PL for .NET, which doesn't support ASP.NET directly (I'm guessing because it doesn't support class implementation inheritance). Consider how JavaScript has been subverted in order to make it play nice with the CLR.

It's quit obvious to me that higher order PLs may contain, and be dependent on, data structures that are very hard to represent or manipulate in lower order PLs. Consider trying to pass the Haskell sequence [0..] to a C function. The enforced interop mandated by the CLR can thus result in some PLs having to dumb-down in order to work well in that environment.

Well, if you do decide to check it out, wait until I put up the next release (1.1RC1), which should come out some time this week.

Can't say I like [JNI] much

Suffice it to say that there's a reason that Jace has a large community.

C represents a low common denominator

That's why I said that it depends upon the languages. For some languages, all I think you're going to get is interop at the C level - That is to say that every language should be capable of expressing a procedural interface. It will be easy to naturally bridge large parts of languages like Java and C++. You'll have less luck bridging languages like Basic and Lisp.

What I don't like about the CLR and Microsoft's strategy, is that they tend to bastardize languages to make them run at all on their platform. In general, I don't think that's what anybody wants. I want to be able to use a language, with all of its esoteric features, to solve the problem that I've chosen it to solve. Then, I'll very deliberately expose certain interfaces to my application/library as cross-language interfaces. I may even make different interfaces depending upon the language I'm interfacing with. I think it's much more likely that we'll come up with a single "best language" than it is that we'll come up with a magic bridge that seamlessly integrates all languages.

Then there's the Jython way (for interpreted languages): write an interpreter for your language in Java bytecode, and run it on the JVM.

The Java libraries and APIs are exposed directly to the interpreter. Jython even resolves Java getFoo/setFoo pairs into Python-style attributes, so that

myObject.setFoo("Bar");

myObject.Foo = "Bar"

There are a couple of Scheme implementations for the JVM I mean to look into soon...

(Addendum) Looking at suggestions to modify the VM to support dynamically-typed languages, it seems to me that if the aim is scripting the performance overheads of having to treat primitive types as Objects etc. will be less of a worry than they would be if the aim were to target a compiler or interpreter at the JVM for purposes of general application development. Scripting often entails most of the work being done by the library code anyway: it's for sequencing calls to an API rather than direct implementation of core functionality.

Jython includes a byte compiler, and will byte compile your programs as needed, so it is better termed a compiler rather then an interpreter.

>Scripting often entails most of the work being done by the library >code anyway: it's for sequencing calls to an API rather than >direct implementation of core functionality.

That is a good point, and probably explains why this jcp will help very little in adding new language support to the vm. If anything, it will help move functionality outside of it.. (which might not be a bad thing)

The existence of fine scripting languages like JScheme, Jython, SISC, et al. indicate that scripting already works pretty well in the JVM.

An interesting piece of work would be to compare the CLR and the JVM as targets for scripting. I have not seen this kind of comparison.