The Dotty project contains three ideas:
- The Dotty programming language
- The
dotc
compiler
- The TASTY serialization format
All of these contribute multiple things:
Dotty: A language based on the DOT Calculus
The DOT Calculus (Dependent Object Types) is a new calculus developed by Martin Odersky's group. It is specifically designed to model a Scala-like language well. It replaces the older ν Object Calculus (that's the Greek letter ν, pronounced something like "new") that was also designed to model Scala, but contained features that were later removed from Scala. DOT is much simpler.
Dotty is a language whose type system and semantics are deeply rooted in the DOT calculus, thus, properties and proofs of the DOT calculus also apply to Dotty.
Dotty: A testbed for further evolution of Scala
Dotty is designed not only to be a superset of DOT calculus, but also to be similar enough to Scala that features tried out and tested in Dotty can be later ported to Scala.
In particular, Dotty has now become the basis of Scala 3, which is a significant re-design of Scala (for example, with Scala 3, Scala will become the first mainstream language to remove Generics from the language, which is exactly the opposite of what other languages like Java, C♯, VB.NET, or C++ have been doing). However, even though Scala 3 is a significant re-design of Scala, it is intended that any code that compiles without warnings and without deprecations in Scala 2.13 can be automatically converted to Scala 3. IOW: the conversion process from Scala 2.13 to Scala 3 is purely mechanical and needs no human intervention.
dotc
: A testbed for novel compiler designs
The dotc
compiler uses a novel design that is inspired by temporal databases. This is completely independent of DOT, the Dotty language, or Scala. It can (and will) be used to improve the Scala compiler, but the ideas can be applied to any compiler for any language.
dotc
: The foundation for a new Scala compiler
dotc
is not just a testbed for novel ideas in compiler design in general, it is also (and that is its second main purpose, after being a compiler for Dotty) the foundation for a complete re-design of the aging New Scala Compiler (the current, second, iteration of the Scala compiler after the original one written in Java).
The design of dotc
allows a lot of features that are expected from modern compilers nowadays that aren't well catered to by traditional batch compiler designs. The job of a modern compiler is not just to turn one language into another (e.g. Scala to JVML), it should
- report (human-readable, clearly understandable) errors
- suggest (and even perform) possible fixes for those errors
- report relevant and helpful warnings
- suggest (and even perform) possible improvements for those warnings
- perform refactorings
- provide lexical, syntactic, and semantic highlighting
- assist code completion
- and do all of that with incomplete code, while the code is being written, instantaneously
NSC's presentation compiler and toolbox can do a lot of that, but dotc
was designed from the ground up with those requirements in mind.
TASTY: a serialization format for semantic trees
The third contribution from the Dotty project is TASTY. TASTY is a serialization format for an intermediate compiler representation that features forwards- and backwards-compatibility, is compact, easy to parse, and contains all information necessary to reconstruct the original program while at the same time leaving out unnecessary detail.
TASTY allows to save the internal representation of a compiler and then load it into a different compiler and continue the compilation.
Why would you want to do this? It allows you to have an intermediate distribution format between source code and binary code (e.g. .class
or .jar
files). Distributing Scala code as .jar
s loses a lot of information about the Scala code. If you then want to link this code with some other Scala code, you may run into problems, especially with Scala 3, which moves some type-safety from the compile-phase to the link-phase.
Distributing it as source code, OTOH, requires that the user needs to have a full Scala development environment in order to use the library.
For those that remember it, the goals are somewhat similar to what ANDF tried to do in the 1980s.