This would be a really nice benefit:
When compiling Scala to Java bytecode each anonymousfunction is implemented as a unique class because the JVM does not have ﬁrst-class functions or closures. However with LLVM we could treat functions as a primitive type, much the same as is done with the JVM primitive types. Special subclasses of the Function class for closures and eta expansion. The closure subclass could be represented in LLVM as a pair containing a pointer to the function and a pointer to the closure context. Likewise the eta expansion subclass could be represented as a pointer to a simple stub that resolves the method can calls it. This would require changes to other parts of the compiler because functions are converted to classes early in the pipeline and ICode has no representation for functions.
Migration Manager allows you, the developer, to take advantage of all the new features of the latest version of Scala while using current versions of your application code that depend on other groups, outside suppliers or on source code you don't have access to.
With Migration Manager, you assemble all of the components of your application and then analyze them for binary compatibility. Using the report mode you can identify incompatibilities and decide whether to obtain a new version, or use the automatic compatibility resolution to fix the problem, deferring the upgrade.
In this experience report we encode a well speciﬁed, compact benchmark in four programming languages, namely C++, Java, Go, and Scala. The implementations each use the languages’ idiomatic container classes, looping constructs, and memory/object allocation schemes. It does not attempt to exploit speciﬁc language and run-time features to achieve maximum performance. This approach allows an almost fair comparison of language features, code complexity, compilers and compile time, binary sizes, run-times, and memory footprint.
links for 2011-06-04