Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ScalaDyno - Making name resolution and type checking fault tolerant

ScalaDyno - Making name resolution and type checking fault tolerant

my semester project at the LAMP lab at EPFL, Switzerland
paper presented at the Scala Workshop 2014 in Uppsala, Sweden
paper: http://infoscience.epfl.ch/record/200962/files/scaladyno-scala14.pdf
code: https://github.com/scaladyno/scaladyno-plugin

Cédric Bastin

May 24, 2015
Tweet

More Decks by Cédric Bastin

Other Decks in Research

Transcript

  1. 29.7.2014 Cédric Bastin, Vlad Ureche - Epfl - In -

    Lamp - Ma1 ScalaDyno Making name resolution and type checking fault tolerant 1
  2. structure of the presentation ✤ Static vs dynamic typing ✤

    How to combine the benefits of both worlds ✤ Contributions of ScalaDyno ✤ Implementation ✤ Demo ✤ Related work 2
  3. •type checking is done during runtime •no type safety at

    runtime; program can fail because of type errors •even obvious errors are only detected at runtime, extensive testing is needed •duck typing / monkey patching statically typed languages dynamic languages •a program needs to be type-correct before it can be executed •little changes might create bigger inconsistency in the entire project •dynamic languages allow easy prototyping and testing without the need for overall consistency •type errors are deferred to runtime => static feedback is useful in big projects which should be stable => dynamic typing is good for fast prototyping •type checking is done at compile time •a program is proved to be correct using the constraints encoded by types •no type errors at runtime (exceptions: e.g. casting...) •compiler can do many optimizations •fast runtime 4
  4. duck-typing ✤ similar to structural subtyping ✤ only methods and

    field which are accessed need to be present 5
  5. It would be nice to have a fusion of both

    type systems ✤ static type-checking should by optional and dynamic typing should be used instead dynamic static 7
  6. Example case class Clazz(x: Int) {
 def square():Int = {x

    * x}
 def inverse():Int = {something with type errors}
 } object NewTest {
 def main(args: Array[String]): Unit = {
 println(Clazz(5).square())
 }
 } 8
  7. ScalaDyno offers a solution! ✤ ScalaDyno is a Scala compiler

    plugin which allows fast prototyping with Scala by deferring type errors to runtime • it doesn’t change the behavior of correctly typed programs • there is no overhead during execution ✤ the plugin can be used during early development phases for fast prototyping and testing • no need to refactor the entire code while doing multiple iterations • releases need to be type correct, work in progress doesn’t, thus can use the plugin 9
  8. the general contributions ✤ developing a method to allow fast

    prototyping in Scala e.g. adding or removing fields, methods or classes ✤ makes it possible to focus only on one execution path in a program ✤ showing how the abstract syntax tree and symbol table 
 consistency can be restored after encountering errors ✤ implementing the theory in a compiler plugin of less than 
 200 lines of code 10
  9. parser 1 parse source into ASTs, perform simple desugaring namer

    2 resolve names, attach symbols to named trees packageobjects 3 load package objects typer 4 typing the AST dyno - ScalaDyno Plugin patmat 5 translate match expressions superaccessors 6 add super accessors in traits and nested classes extmethods 7 add extension methods for inline classes pickler 8 serialize symbol tables where the transformation happens 12
  10. ✤ generally if the reporter would issue an error of

    any kind the compilation process would be aborted ✤ during initialization, the reporter gets replaced with our own personalized reporter which suppresses some errors ✤ only errors from the typer and namer phase gets suppressed ✤ they get replaced with an warning which caries the same information ✤ in addition the error message gets recorder to be used later on Tricking the compiler 14
  11. cleanup the erroneous AST ✤ after the typing phase we

    need to modify the AST such that it does no longer contain erroneously typed branches ✤ we replace the branches with error types with Exception statements which contain the corresponding error message ✤ we do not alter the AST if no error is present 15
  12. ✤ we extend the predefined Transformer to implement this behavior

    and give special treatments to some AST branches ✤ We recursively run over the AST and look for erroneous branches ✤ Exceptions cannot be thrown any where in the code (e.g. pattern matching) ✤ we “bubble up” the error to a position where it is safe to throw the exception 16
  13. keeping the AST type-correct ✤ Scala type ErrorType behaves like

    the type Nothing which is the subtype of any other type ✤ Exception have type ErrorType and can thus be injected on any branch of the AST without breaking type correctness ✤ We can also remove erroneous symbols from the symbol table as they can only lead to spurious error messages 17
  14. Related Work ✤ make a dynamically typed language more static

    ✤ make a statically typed language more dynamic 19
  15. Proxies: add additional step in typing when resolving a member

    access: ➡ Scala-Virtualized: check if the scope contains the definition inflix_methodName(inst, args) ➡ look in the class of the instance as well as in the parents from the inheritance structure ➡ check for an implicit conversion ➡ Dynamic trait: check if the type is Dynamic and use inst.applyDynamic(“name”) 23
  16. Future work ✤ make ScalaDyno suppress RefCheck errors as well

    ✤ make ScalaDyno more robust for usage with sbt 27
  17. Cédric Bastin 20.06.2014 code and examples are available on github:

    https://github.com/scaladyno/scaladyno-plugin big thanks to my supervisor Vlad Ureche who took time for our weekly meetings and giving me always good advice and help with the implementation 28