How to view Scala code without all the syntactic sugar

scalasyntax

I have been studying Scala, but what I keep running into is the optimization of syntax. I'm sure that will be great when I am an expert, but until then.. Not so much.

Is there a command or a program that that would add back in all/most of the code that was optimized away? Then I would be able to read the examples, for example.

Best Answer

You can use -print when compiling Scala, and it will print a de-sugared version of the code. Unfortunately, you'll see that Scala has syntactic sugar for good reason.

Let's see a very simple example:

object T {
  def first[A : Ordering](l: List[A]): A = {
    val s = l.sorted
    s(0)
  }
}

And the output:

package <empty> {
  final object T extends java.lang.Object with ScalaObject {
    def first(l: List, evidence$1: scala.math.Ordering): java.lang.Object = {
      val s: List = l.sorted(evidence$1).$asInstanceOf[List]();
      s.apply(0)
    };
    def this(): object T = {
      T.super.this();
      ()
    }
  }
}

You'll often see things like <empty> -- these are compiler annotations, not valid Scala code. For example, a parameter in a case class will have its getter tagged with <stable> <caseaccessor> <accessor> <paramaccessor>. Also, a case class will have a number of methods marked <synthetic>, to indicate they were created by the compiler.

Also, the this constructor you see here is not valid Scala code, exactly. In this case, the "normal" Scala constructor (which is the body of the class, trait or object) is moved inside such a this method -- which is how Java itself sees things.

So, this is mixture of Scala and Java, with a bit of compiler internals sprinkled over it. But it will show the de-sugared stuff.

Related Solutions

Scala Async – Best Practices for APIs Returning Futures

If you are talking async and futures in Scala, it is imperative that you read SIP-14: Futures and Promises. There were also some extensive discussions about it on the SIP mailing list, which is a google group, so you can find its archives.

JVM Tail-Call Optimization – Limitations in Scala and Clojure

Now, I don't know much about Clojure and little about Scala, but I'll give it a shot.

First off, we need to differentiate between tail-CALLs and tail-RECURSION. Tail recursion is indeed rather easy to transform into a loop. With tail calls, it's much harder to impossible in the general case. You need to know what is being called, but with polymorphism and/or first-class functions, you rarely know that, so the compiler cannot know how to replace the call. Only at runtime you know the target code and can jump there without allocating another stack frame. For instance, the following fragment has a tail call and does not need any stack space when properly optimized (including TCO), yet it cannot be eliminated when compiling for the JVM:

function forward(obj: Callable<int, int>, arg: int) =
    let arg1 <- arg + 1 in obj.call(arg1)

While it's just a tad inefficient here, there are whole programming styles (such as Continuation Passing Style or CPS) which have tons of tail calls and rarely ever return. Doing that without full TCO means you can only run tiny bits of code before running out of stack space.

What facility of the underlying virtual machine would allow the compiler to handle TCO more easily?

A tail call instruction, such as in the Lua 5.1 VM. Your example does not get much simpler. Mine becomes something like this:

push arg
push 1
add
load obj
tailcall Callable.call
// implicit return; stack frame was recycled

As a sidenote, I would not expect actual machines to be much smarter than the JVM.

You're right, they aren't. In fact, they are less smart and thus don't even know (much) about things like stack frames. That's precisely why one can pull tricks like re-using stack space and jumping to code without pushing a return address.

Best Answer

Related Solutions

Scala Async – Best Practices for APIs Returning Futures

JVM Tail-Call Optimization – Limitations in Scala and Clojure

Related Topic