Scalight = Scala language MINUS scala-library
This is just at the concept phase right now, there's not even a prototype to try out, but your feedback is welcome (see below)
If Java is the JVM's assembler and Scala is it's C++, then Scalight aims at becoming its embedded C language.
The goal of Scalight is to provide a minimalistic subset of the Scala language with virtually no runtime dependency on Scala-the-library (let's say less than 100kB of runtime dependencies as a first goal).
Of course, this means getting a language that's close to Scala by the syntax but closer to raw Java by the power (hopefully still much more concise than Java, though).
Scala is a great language with countless advantages, and it is rather tightly coupled to its great runtime library.
However, that library has grown big, as in 6-8MB big, and it's hard to imagine it could ever go back below 5 MB.
That's okay for fat desktop or server apps, but probably slightly less so for Android or other embedded / real-time situations (where any library that creates lots of objects can be a threat anyway).
Although one of my long-term goals is to make Scala a natural alternative to Java on the Android platform (for smaller apps, no proguard...), not having to depend on scala-library anymore might eventually make Scala (the language) more appealing to some Java software houses that see any new library dependency as a liability... What do you think ?
... there are other projects much more advanced that help writing Scala programs for Android, and they'll always be infinitely superior to Scalight (if only, because they retain the full power of Scala).
I haven't tested any of them yet, but here's a raw list for you to try :
And probably lots more... Long story short : if you want to program on Android (or anywhere else) with the full Scala language & libraries, Scalight is definitely not for you.
Plan is to provide / keep the following features :
- Java collection wrappers that roughly mimic (mutable) Scala collections, yet with absolutely no runtime dependencies (hehe, we've got some magic in stock to achieve that, please read on)
- Closures
- For loops...
- Case classes, tuples & their pattern-matching
Something similar in the programming space to Frankenstein's experiments... (can Scala's adult brains fit inside a doll's body ?)
Please remember : I'm currently just playing with this idea and I'm looking for positive / negative feedback (I know it has many attributes of a bad good idea, plus some of those of a good bad idea).
We'd provide a static library that covers :
- Minimalistic DSL that wraps Java collections and makes them look and feel like Scala collections : you'll get basic map, filter, foreach, reduce & fold, reverse, takeWhile & dropWhile, groupBy operations on java.util.List and java.util.Map
- Minimalistic DSL for Dynamic type (aliased to Object)
- Ultra-minimalistic and naive parallel list (syntactic sugar for List of Futures)
That static library would, by definition, not be needed at runtime : the magic in place here would be a compiler plugin that inlines the static library methods straight into the compiled code, which doesn't depend on anything but regular Java APIs in the end. And since the static library only relies on type aliases of Java types, there's really nothing to depend upon at runtime !
To be more precise, that compiler plugin would just be a derivative from Scalaxy, with many compilets to make the code dependency-free and an extra compiler phase that throws errors at whatever unsupported Scala API call that remains in the user code after the compilets.
These compilets would have to cover all of the static library and most (if not all) of scala.runtime.RichX classes.
In addition to that static library, a minimalistic core-Scala runtime library would still contain some basic classes, hard (although not impossible) to avoid :
- Tuples & Product (maybe not needed, could encode them with Object arrays)
- Function & PartialFunction (maybe not needed, could enforce the use of inlineable closures)
As a future extension, a more extreme scalighter mode might be added with flattening of tuples and inlining of functions
That's it !
Please note that it's not the first time I try to trim Scala down : I'm guilty of writing ScalaCL, which converts a tiny subset of Scala to OpenCL and hence needed to get any runtime dependency of the converted code out of the way. This idea / project is a natural consequence of that first experience.