Adriaan Moors Martin Odersky Preparing For Scala 3 Adriaan Moors Martin Odersky Scala Days New York June 2018 OPEN GAMBIT Multicore. Cloud computing. Containers. You’ll likely agree that the infrastructure for amazing scalability is in place, it’s been well funded. It’s the underpinning that’s required for enterprises to movie en masse to the cloud. But what are they moving? Applications. Applications that run their business, engage their customers, allow them to innovate and enter new markets. Without applications, this infinitely scalable infrastructure is nothing.

Roadmap (from previous years) This is open source work, depends on community’s contributions.  Roadmap is tentative, no promises: 2016 backend, classpath handling Scala 2.12 2017 stdlib collections Dotty 0.1 “MVP” = minimal viable prototype 2018 Scala 2.13 Dotty 0.x releases TASTY, middle end? Scala 2.14 migration Scala 3.0 Scala 2.15?

Roadmap (now) Early 2020 2016 Scala 2.12 2017 Dotty 0.1 2018 This is open source work, depends on community’s contributions.  Roadmap has held up pretty well so far! 2016 backend, classpath handling Scala 2.12 2017 stdlib collections Dotty 0.1 “MVP” = minimal viable prototype 2018 Scala 2.13 Dotty 0.x releases TASTY, middle end? Early 2020 Scala 2.14 migration Scala 3.0 Early 2020

Why Scala 3 ?

The Essence of Scala: Fusion of functional and object-oriented programming

The Essence of Scala: Fusion of functional and object-oriented programming in a typed setting functions for the logic objects for the modularity

Success! Starting from a statically typed OO core language, Scala pioneered closures, function types, expression orientation, tuples, local type inference, pattern matching, traits, lazy vals, by-name parameters, x:T syntax, dependent types, implicit parameters, and more Many other languages followed suit by adopting some of these features: C#, Kotlin, Swift, Java, … 🎉

Derailing It Scala as a worse Haskell for the JVM A better Java, without Scala’s deep parts Both take one half of Scala’s features, but ignore the synthesis

Derailing It Haskalator: Scala as a worse Haskell for the JVM Haskell is a great language But Scala is not a good basis for emulating all Haskell patterns If you choose to ignore Scala’s OOP parts, there’s little point in using it at all!

Derailing It A better Java, without Scala’s deep parts new languages such as Kotlin, Swift, improved languages such as C#, Java trade abstraction & composition for more ad-hoc features, avoid the more esoteric FP parts by making it less pleasant to express them.  larger language, simpler programs?

The Way Forward We believe Scala’s fusion of FP and OOP is still the most promising way forward for general purpose software development. But…

The Way Forward But there are lots of things we have learned since the inception of Scala, including how to be pure without sacrificing simplicity and performance how to do meta programming, safely how to cut down on boilerplate for new idioms

The Way Forward Incorporate these new techniques in the language, to make it simpler, more focused, and more pleasant to use.

Realizing Scala’s Potential become more opinionated simplify eliminate inconsistencies and puzzlers build on strong foundations consolidate language constructs to improve consistency safety ergonomics performance

Consistency Improve orthogonality and eliminate restrictions: Intersection types  A & B Union types A | B Implicit function types implicit A => B Dependent function types (x: A) => x.B Trait parameters trait T(x: A) Generic tuples (a, b, c) == (a, (b, (c, ()))

Ergonomics Make code readable and concise Enums   enum Color { case Red, Green, Blue } Type lambdas [X] => F[X]

Safety Enable precise domain modeling and safe refactoring. Multiversal equality List(“a”) == “b” Restrict implicit conversions Also planned: Null safety String | Null Effect capabilities

Performance Make abstractions cheaper: Opaque types opaque type A = B Erased parameters def f(erased x: A =:= B)

Removed existential types using forSome procedure syntax early initiliazers XML literals limit 22 automatic () insertion weak conformance auto-tupling multi-parameter infix operators

Implicit Improvements Implicits turned out to be where Scala innovated most. They can be both a blessing and a curse. Goal for Scala 3: Fewer curses!  Simplicitly, POPL 2018

Implicit Conversions Implicit Parameters so far: Implicit Conversions Implicit Parameters consistency - intersection types - dependent function types - type lambdas (avoids turing complete & unsound encodings) expressiveness - union types - implicit function types - enums - extension clauses - kind polymorphism safety - Null - effects - multiversal equality performance - erased parameters - opaque type aliases

Implicit Parameters consistency - intersection types in the future: Implicit Conversions Implicit Parameters consistency - intersection types - dependent function types - type lambdas (avoids turing complete & unsound encodings) expressiveness - union types - implicit function types - enums - extension clauses - kind polymorphism safety - Null - effects - multiversal equality performance - erased parameters - opaque type aliases

Cutting-down on implicit conversions Extension clauses can subsume most valid use cases: case class Circle(x: Double, y: Double, radius: Double) extension CircleOps for Circle { def circumference = radius * Pi * 2 } instead of implicit class CircleOps(circle: Circle) extends AnyVal { def circumference = circle.radius * Pi * 2 consistency - intersection types - dependent function types - type lambdas (avoids turing complete & unsound encodings) expressiveness - union types - implicit function types - enums - extension clauses - kind polymorphism safety - Null - effects - multiversal equality performance - erased parameters - opaque type aliases

*exempted are only conversions co-defined with their target type Cutting-down on implicit conversions Most other uses (not just definitions!) require a language import: import language.implicitConversions implicit def str2int(x: String) = x.toInt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ val x: Int = “123” consistency - intersection types - dependent function types - type lambdas (avoids turing complete & unsound encodings) expressiveness - union types - implicit function types - enums - extension clauses - kind polymorphism safety - Null - effects - multiversal equality performance - erased parameters - opaque type aliases *exempted are only conversions co-defined with their target type

Making Implicit Parameters more Useful def f(implicit x: A) (y: B) (implicit z: C) = … f.explicitly(a)(b) implicit A => B Multiple implicit clauses Explicit applications Implicit function types consistency - intersection types - dependent function types - type lambdas (avoids turing complete & unsound encodings) expressiveness - union types - implicit function types - enums - extension clauses - kind polymorphism safety - Null - effects - multiversal equality performance - erased parameters - opaque type aliases

Implicit Function Types: get purity without sacrificing simplicity and performance. consistency - intersection types - dependent function types - type lambdas (avoids turing complete & unsound encodings) expressiveness - union types - implicit function types - enums - extension clauses - kind polymorphism safety - Null - effects - multiversal equality performance - erased parameters - opaque type aliases

Tooling So far, we have: a new compiler: dotc rich IDE support through LSP with direct support for VS Code. REPL Doc-tool Most tooling is built around Tasty

Tasty Typed abstract syntax trees serialization format for Scala complete position and type information all implicits are expanded out surprisingly compact (~ same size as source)

macros analyzers optimizers The Tasty Vision IDE .class (Java 8) .scala (2.x) LSP .scala (3.x) .class (Java 11) Tasty .js macros analyzers optimizers .out

Tasty Use Cases Separate compilation Language servers for IDEs (via LSP) Macros Cross-building  escape the curse of binary compatibility

Meta Programming, So Far Def macros (experimental), macro paradise (plugin). - Both are thin veneers around nsc. Scala Meta: External tools that analyze and transform programs.

Principled Meta Programming 2 + 2 fundamental operators: ‘( … ) (quote) ~(...) (splice) run inline Quote, splice + inline : macros Quote, splice + run : staging

Principled Meta Programming T Expr[T] Restriction: Can’t look inside an Expr. quote ‘(…) splice ~(…)

Principled Meta Programming T Expr[T] tasty.Tree Solution: Bijection between Expr[T] (high-level) and tasty.Tree (low-level) quote ‘(…) reflect splice ~(…) reify

macros analyzers optimizers The Tasty Vision IDE .class (Java 8) .scala (2.x) LSP .scala (3.x) .class (Java 11) Tasty .js macros analyzers optimizers .out

New Macros are “Blackbox” They get expanded after type checking. Program must typecheck before macros are expanded Macros always work on typed trees Hygienic by definition Drastically reduces # things that can go wrong

Language-Level Solutions for Lazy implicits ✔ Type lambdas ✔ Context injection ✔ Typeclass derivation (still to do) Typelevel functions (working on it)

Type Level Programming Today: Use implicits Looks like logic programming with your hands tied behind your back.

Type Level Programming Tomorrow: Partial evaluation of functions

Meta Programming Levels Level 0: transparent functions for type specialization. Level 1: quotes & splices Level 2: Tasty reflection Safety Power

Migration Despite many differences, Scala 2 and 3 are still fundamentally the same language Source compatibility for common subset. Rewrite tools can handle much of the rest (macros are the big exception here). Situation better than for Python 2 vs 3 because of static typing & binary compatibility.

Binary Compatibility Dotty module Scala 2 module today: Dotty can link with Scala-2.12 class files. Dotty module Scala 2 module

Binary Compatibility Scala 3 module Scala 2 module Scala 3 module today: Dotty can link with Scala-2.12 class files. planned: Two way compatibility using Tasty as common intermediate format. Scala 3 module Scala 2 module Scala 3 module Scala 2 module

Roadmap Get feedback Refinements Scala 3 Stabilization dev previews 2018 Flesh out design Dotty 0.x Get feedback Refinements 2019, first half -------------- Feature freeze --------------- Scala 3 Stabilization dev previews 2020, first half Scala 3.0

Stability So far: Most Scala 2 regression tests are in the Scala 3 test suite. Community build for core libraries and tools. All tools are built using Scala 2 first, and then again with dotc.

Stability Planned: Once there are developer previews, ensure that core projects are published for Scala 3. Use dotc itself as the bootstrap root. “eat our own dogfood” should use Scala 3 features in our own tools.

Try It Out Today! dotty.epfl.ch New versions are released every 6 weeks.

Questions, Suggestions, Concerns? Talk to us anytime. Also, there’s a panel where we will respond to questions at the end of the conference.