Work in Progress

Scala 3 has not been released, yet. We are still in the process of writing the documentation for Scala 3. You can help us to improve the documentation.

Are you searching for the Scala 2 documentation?

 

An Overview of TASTy

Language

If you create a Scala 3 source code file named Hello.scala:

@main def hello = println("Hello, world")

and then compile that file with scalac:

$ scalac Hello.scala

you’ll notice that amongst other resulting files, scalac creates files with the .tasty extension:

$ ls -1
Hello$package$.class
Hello$package.class
Hello$package.tasty
Hello.scala
hello.class
hello.tasty

This leads to the natural question, “What is tasty?”

What is TASTy?

TASTy is an acronym that comes from the term, Typed Abstract Syntax Trees. It’s a high-level interchange format for Scala 3, and in this document we’ll refer to it as Tasty.

A first important thing to know is that Tasty files are generated by the scalac compiler, and contain all of the information about your source code, including the syntactic structure of your program, and complete information about types, positions, and even documentation. Tasty files contain much more information than .class files, which are generated to run on the JVM. (More on this shortly.)

In Scala 3, the compilation process looks like this:

         +-------------+    +-------------+    +-------------+
$ scalac | Hello.scala | -> | Hello.tasty | -> | Hello.class |
         +-------------+    +-------------+    +-------------+
                ^                  ^                  ^
                |                  |                  |
           Your source        TASTy file         Class file
               code           for scalac        for the JVM
                              (contains         (incomplete
                               complete         information)
                             information)

The issue with .class files

Because of issues such as type erasure, .class files are actually an incomplete representation of your code. A simple way to demonstrate this is with a List example.

Type erasure means that when you write Scala code like this that’s supposed to run on the JVM:

val xs: List[Int] = List(1, 2, 3)

that code is compiled to a .class file that needs to be compatible with the JVM. As a result of that compatibility requirement, the code inside that class file — which you can see with a javap command — ends up looking like this:

public scala.collection.immutable.List<java.lang.Object> xs();

That javap command output shows a Java representation of what’s contained in the class file. Notice in this output that xs is not defined as a List[Int] any more; it’s essentially represented as a List[java.lang.Object]. For your Scala code to work with the JVM, the Int type has been erased.

Later, when you access an element of your List[Int] in your Scala code, like this:

val x = xs(0)

the resulting class file will have a casting operation for this line of code, which you can think of being like this:

int x = (Int) xs.get(0)               // Java-ish
val x = xs.get(0).asInstanceOf[Int]   // more Scala-like

Again, this is done for compatibility, so your Scala code can run on the JVM. However, the information that we already had a list of integers is lost in the class files. This poses problems when trying to compile a Scala program against an already compiled library. For this, we need more information than usually available in class files.

And this discussion only covers the topic of type erasure. There are similar issues for every other Scala construct that the JVM isn’t aware of, including constructs like unions, intersections, traits with parameters, and many more Scala 3 features.

TASTy to the Rescue

So, instead of having no information about the original types in .class files, or only the public API (as with the Scala 2.13 “Pickle” format), the TASTy format stores the complete abstract syntax tree (AST), after type checking. Storing the whole AST has a lot of advantages: it enables separate compilation, recompilation for a different JVM version, static analysis of programs, and many more.

Key points

So that’s the first takeaway from this section: The types you specify in your Scala code aren’t represented completely accurately in .class files.

A second key point is to understand that there are differences between the information that’s available at compile time and run time:

  • At compile time, as scalac reads and analyzes your code, it knows that xs is a List[Int]
  • When the compiler writes your code to a class file, it writes that xs is a List[Object], and it adds casting information everywhere else xs is accessed
  • Then at run time — with your code running inside the JVM — the JVM doesn’t know that your list is a List[Int]

With Scala 3 and Tasty, here’s another important note about compile time:

  • When you write Scala 3 code that uses other Scala 3 libraries, scalac doesn’t have to read their .class files any more; it can read their .tasty files, which, as mentioned, are an exact representation of your code. This is important to enable separate compilation and compatiblity between Scala 2.13 and Scala 3.

Tasty benefits

As you can imagine, having a complete representation of your code has many benefits:

  • The compiler uses it to support separate compilation.
  • The Scala Language Server Protocol-based language server uses it to support hyperlinking, command completion, documentation, and also for global operations such as find-references and renaming.
  • Tasty makes an excellent foundation for a new generation of reflection-based macros.
  • Optimizers and analyzers can use it for deep code analysis and advanced code generation.

In a related note, Scala 2.13.4 has a TASTy reader, and the Scala 3 compiler can also read the 2.13 “Pickle” format. The Compatibility Reference in the Scala 3 Migration Guide summarizes the benefits of this cross-compiling capability:

“You can have a Scala 2.13.4 module that depends on a Scala 3.0.0-M1 module, and the latter can even depend on another Scala 2.13.4 module. >Cross-compatibility will not restrain you from using the exciting new features of Scala 3.0. In short, we have backward and forward compatibility and so migration can happen gradually and in any order.”

More information

In summary, Tasty is a high-level interchange format for Scala 3, and .tasty files contain a complete representation of your source code, leading to the benefits outlined in the previous section.

For more details, see these resources:

These articles provide more information about Scala 3 macros:

Contributors to this page: