I just watched the talk, and it is full of insight. Highly recommended even if you've never used Scala (as I have not).
Some samples (some are quotes, some are paraphrased):
* "The compiler [should be] designed around inputs which are Diff[T]s against an in-memory understanding of the last successful compilation.... As a result, both Repl and Debugger are superfluous as separate tools." (emphasis mine)
* "I want to programmatically generate ASTs and feed them in"
* The AST (the tree) is fundamental, not the language. For example, if you have an AST you're working with, and you hate curly braces, theoretically you could see the same tree "rendered" as text without those curly braces.
* "True power is in restriction" & "unnecessary expressiveness is the enemy" -- whatever your language lets you "say", the "other side" (the compiler or interpreter) has to be able to understand. So unlimited language means horribly over-complicated compiler that cannot do nearly as much optimization as you'd like.
* The more free your code is of "over-precision", the more powerful that code is, because the compiler can do more with it. Example: the well known example of an imperative for-loop versus the functional "map".
> "The compiler [should be] designed around inputs which are Diff[T]s against an in-memory understanding of the last successful compilation.... As a result, both Repl and Debugger are superfluous as separate tools." (emphasis mine)
We did something like this before with scalac back in 2007. But they eventually decided to use lazy rather than incremental evaluation after I left the project (I admit the tech was too crazy and under developed for the time).
But the approach wound up working very well, check out:
I'd imagine it would work well for Scala today (it took about 6 months to retrofit scalac in 2007, and most of this was just polishing positions for memoization + getting rid of object identities). However, TypeSafe's current approach to reactive programming seems to revolve around Rx and actors, which isn't very useful in a compiler or live interpreter.
> The AST (the tree) is fundamental, not the language. For example, if you have an AST you're working with, and you hate curly braces, theoretically you could see the same tree "rendered" as text without those curly braces.
Ya, but all of this can be done in the IDE. Also, projectional editing isn't quite their yet; I prefer hacks like "Little Braces" for Visual Studio that simply shrink brace-only lines to very small font sizes :) Of course, I think syntax is "language", and having multiple languages flying around isn't great for community building.
Doesn't Ocamlpp4 or whatever its called generate OCaml source code and pass that to the compiler, not OCaml AST? The new ppx extension in 4.02 allows direct manipulation of OCaml AST, but that hasn't been used enough yet to determine its effectiveness.
In fact, towards the end of the talk, I was thinking "Wow, he sounds almost as ambitious as Bret Victor." Then, the next slide was a picture and some quotes from Bret Victor. :)
Some samples (some are quotes, some are paraphrased):
* "The compiler [should be] designed around inputs which are Diff[T]s against an in-memory understanding of the last successful compilation.... As a result, both Repl and Debugger are superfluous as separate tools." (emphasis mine)
* "I want to programmatically generate ASTs and feed them in"
* The AST (the tree) is fundamental, not the language. For example, if you have an AST you're working with, and you hate curly braces, theoretically you could see the same tree "rendered" as text without those curly braces.
* "True power is in restriction" & "unnecessary expressiveness is the enemy" -- whatever your language lets you "say", the "other side" (the compiler or interpreter) has to be able to understand. So unlimited language means horribly over-complicated compiler that cannot do nearly as much optimization as you'd like.
* The more free your code is of "over-precision", the more powerful that code is, because the compiler can do more with it. Example: the well known example of an imperative for-loop versus the functional "map".
* "If you want fast, start with comprehensible."