![Ergonomics
Make code readable and concise
• Enums enum Color {
case Red, Green, Blue
}
• Type lambdas [X] => F[X]](https://image.slidesharecdn.com/scaladaysberlin-180517100049/85/Preparing-for-Scala-3-19-320.jpg)
![Principled Meta Programming
T Expr[T]
Restriction: Can’t look inside an Expr.
splice ~(…)
quote ‘(…)](https://image.slidesharecdn.com/scaladaysberlin-180517100049/85/Preparing-for-Scala-3-36-320.jpg)
![Principled Meta Programming
T Expr[T] tasty.Tree
Solution: Bijection between Expr[T] (high-level)
and tasty.Tree (low-level)
reflect
reifysplice ~(…)
quote ‘(…)](https://image.slidesharecdn.com/scaladaysberlin-180517100049/85/Preparing-for-Scala-3-37-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Preparing for Scala 3 (20)
Ad
More from Martin Odersky (14)
Ad
Recently uploaded (20)
Preparing for Scala 3
- 1. Preparing For Scala 3 Adrian Moors Martin Odersky Scala Days Berlin April 2018
- 2. Roadmap (from previous years) Scala 2.12 Scala 2.13 Scala 3.0 TASTY, middle end? stdlib collections Dotty 0.1 Dotty 0.x releases 2016 backend, classpath handling Scala 2.14 2017 2018 This is open source work, depends on community’s contributions. à Roadmap is tentative, no promises: “MVP” = minimal viable prototype Scala 2.15? migration
- 3. Roadmap (now) Scala 2.12 Scala 2.13 Scala 3.0 TASTY, middle end? stdlib collections Dotty 0.1 Dotty 0.x releases 2016 backend, classpath handling Scala 2.14 2017 2018 This is open source work, depends on community’s contributions. à Roadmap has held up pretty well so far! “MVP” = minimal viable prototype migration Early 2020 Early 2020
- 4. License Change http://scala-lang.org/news/license-change.html BSD 3 à Apache v2.0 Concerns? let us know by Aug 10
- 5. Developer Survey http://scala-lang.org/news/survey-2018.html Would love to hear from you! Takes 15 min
- 6. Why Scala 3 ?
- 7. The Essence of Scala: Fusion of functional and object-oriented programming
- 8. The Essence of Scala: Fusion of functional and object-oriented programming in a typed setting • functions for the logic • objects for the modularity
- 9. 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, … 🎉
- 10. 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
- 11. 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!
- 12. 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?
- 13. 0 200 400 600 800 1000 1200 1400 1600 python haskell scala kotlin swift java8 c++ csharp Grammar size in lines Grammar size in lines
- 14. 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…
- 15. The Way Forward But there are lots of things we have learned since the inception of Scala, including 1. how to be pure without sacrificing simplicity and performance 2. how to do meta programming, safely 3. how to cut down on boilerplate for new idioms
- 16. The Way Forward Incorporate these new techniques in the language, to make it simpler, more focused, and more pleasant to use.
- 17. 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
- 18. 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, ()))
- 19. Ergonomics Make code readable and concise • Enums enum Color { case Red, Green, Blue } • Type lambdas [X] => F[X]
- 20. Safety Enable precise domain modeling and safe refactoring. • Multiversal equality List(“a”) == “b” • Restrict implicit conversions Also planned: • Null safety String | Null • Effect capabilities
- 21. Performance Make abstractions cheaper: • Opaque types opaque type A = B • Erased parameters def f(erased x: A =:= B)
- 22. Removed • existential types using forSome • procedure syntax • early initiliazers • XML literals • limit 22 • automatic () insertion • weak conformance • auto-tupling • multi-parameter infix operators
- 23. 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
- 24. so far: Implicit Conversions Implicit Parameters
- 25. in the future: Implicit Conversions Implicit Parameters
- 26. 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 }
- 27. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ import language.implicitConversions val x: Int = “123” *exempted are only conversions co-defined with their target type
- 28. Making Implicit Parameters more Useful Multiple implicit clauses Explicit applications Implicit function types def f(implicit x: A) (y: B) (implicit z: C) = … f.explicitly(a)(b) implicit A => B
- 29. Implicit Function Types: get purity without sacrificing simplicity and performance.
- 30. 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
- 31. 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)
- 32. The Tasty Vision Tasty .scala (2.x) .scala (3.x) .class (Java 8) .js .class (Java 11) .out macros analyzers optimizers IDE LSP
- 33. Tasty Use Cases • Separate compilation • Language servers for IDEs (via LSP) • Macros • Cross-building à escape the curse of binary compatibility
- 34. 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.
- 35. Principled Meta Programming 2 + 2 fundamental operators: ‘( … ) (quote) ~(...) (splice) run inline Quote, splice + inline : macros Quote, splice + run : staging
- 36. Principled Meta Programming T Expr[T] Restriction: Can’t look inside an Expr. splice ~(…) quote ‘(…)
- 37. Principled Meta Programming T Expr[T] tasty.Tree Solution: Bijection between Expr[T] (high-level) and tasty.Tree (low-level) reflect reifysplice ~(…) quote ‘(…)
- 38. The Tasty Vision Tasty .scala (2.x) .scala (3.x) .class (Java 8) .js .class (Java 11) .out macros analyzers optimizers IDE LSP
- 39. 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
- 40. Language-Level Solutions for Lazy implicits ✔ Type lambdas ✔ Context injection ✔ Typeclass derivation (still to do) Typelevel functions (to be explored)
- 41. 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.
- 42. Binary Compatibility today: Dotty can link with Scala-2.12 class files. Scala 2 module Dotty module
- 43. Binary Compatibility today: Dotty can link with Scala-2.12 class files. planned: Two way compatibility using Tasty as common intermediate format. Scala 2 module Scala 3 module Scala 2 module Scala 3 module
- 44. Roadmap 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
- 45. 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.
- 46. 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.
- 47. Try It Out Today! dotty.epfl.ch New versions are released every 6 weeks.
- 48. Questions, Suggestions, Concerns? Talk to us anytime. Also, there’s a panel where we will respond to questions at the end of the conference. Plus, a contributors workshop on Friday. Talk to Heather if you want to go.