Martin Odersky - Evolution of Scala
5 likes•1,592 views
The document summarizes the evolution of the Scala programming language from its origins to its present state and future directions. It discusses Scala's combination of object-oriented and functional programming, its type system, tooling improvements, and the emergent ecosystem around Scala. It also outlines plans to develop a Scala-specific platform called TASTY and explore new language concepts like effect systems to model side effects through capabilities.
![Why <XML>?
I wanted Scala to have a hipster syntax.
• Everybody uses [..] for arrays, so we use (..)
• Everybody uses <..> for types, so we use [..]
• But now we needed to find another use of <..>](https://image.slidesharecdn.com/adp0bk1tqygmtszt6q83-signature-276dfc56a946860059422f2305a777961fd612dac3f81af11bf4dfa0aac7fa49-poli-150514072748-lva1-app6891/85/Martin-Odersky-Evolution-of-Scala-6-320.jpg)
![More Simplifications
Existential types
List[T]
forSome
{
type
T},
List[_]
Higher-kinded types
List
à Type with uninstantiated type members
List](https://image.slidesharecdn.com/adp0bk1tqygmtszt6q83-signature-276dfc56a946860059422f2305a777961fd612dac3f81af11bf4dfa0aac7fa49-poli-150514072748-lva1-app6891/85/Martin-Odersky-Evolution-of-Scala-34-320.jpg)
![expands to
Type Parameters as Syntactic Sugar
class
List[T]
{
...
}
class
List
{
type
List$T
private
type
T
=
List$T
}](https://image.slidesharecdn.com/adp0bk1tqygmtszt6q83-signature-276dfc56a946860059422f2305a777961fd612dac3f81af11bf4dfa0aac7fa49-poli-150514072748-lva1-app6891/85/Martin-Odersky-Evolution-of-Scala-35-320.jpg)
![expands to
General Higher-Kinded Types
through Typed Lambdas
type
Two[T]
=
(T,
T)
type
Two
=
Lambda
{
type
hk$Arg
type
Apply
=
(hk$arg,
hk$arg)
}](https://image.slidesharecdn.com/adp0bk1tqygmtszt6q83-signature-276dfc56a946860059422f2305a777961fd612dac3f81af11bf4dfa0aac7fa49-poli-150514072748-lva1-app6891/85/Martin-Odersky-Evolution-of-Scala-36-320.jpg)
![expands to
General Higher-Kinded Types
through Typed Lambdas
Two[String]
Two
{
type
hk$Arg
=
String
}
#
Apply](https://image.slidesharecdn.com/adp0bk1tqygmtszt6q83-signature-276dfc56a946860059422f2305a777961fd612dac3f81af11bf4dfa0aac7fa49-poli-150514072748-lva1-app6891/85/Martin-Odersky-Evolution-of-Scala-37-320.jpg)
![1. Implicits that compose
We already have implicit lambdas
implicit
x
=>
t
implicit
transaction
=>
body
What about if we also allow implicit function types?
implicit
Transaction
=>
Result
Then we can abstract over implicits:
type
Transactional[R]
=
implicit
Transaction
=>
R
Types like these compose, e.g.
type
TransactionalIO[R]
=
Transactional[IO[R]]](https://image.slidesharecdn.com/adp0bk1tqygmtszt6q83-signature-276dfc56a946860059422f2305a777961fd612dac3f81af11bf4dfa0aac7fa49-poli-150514072748-lva1-app6891/85/Martin-Odersky-Evolution-of-Scala-41-320.jpg)
![expands to
New Rule:
If the expected type of an expression E is an implicit
function, E is automatically expanded to an implicit closure.
def
f:
Transactional[R]
=
body
def
f:
Transactional[R]
=
implicit
_:
Transaction[R]
=>
body](https://image.slidesharecdn.com/adp0bk1tqygmtszt6q83-signature-276dfc56a946860059422f2305a777961fd612dac3f81af11bf4dfa0aac7fa49-poli-150514072748-lva1-app6891/85/Martin-Odersky-Evolution-of-Scala-42-320.jpg)
![use this
Idea: Use implicits to model effects as
capabilities
def
f:
R
throws
Exc
=
...
def
f(implicit
t:
CanThrow[Exc]):
R
=
...
instead of this
type
throws[R,
Exc]
=
implicit
CanThrow[Exc]
=>
R
or add this
to get back to this!](https://image.slidesharecdn.com/adp0bk1tqygmtszt6q83-signature-276dfc56a946860059422f2305a777961fd612dac3f81af11bf4dfa0aac7fa49-poli-150514072748-lva1-app6891/85/Martin-Odersky-Evolution-of-Scala-45-320.jpg)
Martin Odersky - Evolution of Scala
- 1. The Evolution of Scala Martin Odersky Scala Italy 2015
- 2. “Scala” is going nowhere “Scala is a gateway drug to Haskell” Recognizing this fact, we should phase out the name “Scala” Idea and Design: Sandro Stucky
- 4. Where It Came From 1980s Modula-2, Oberon 1990-95 Functional Programming: λ calculus, Haskell, SML 1995-98 Pizza 1998-99 GJ, javac 2000-02 Functional Nets, Funnel 4
- 5. Motivation for Scala • Grew out of Funnel • Wanted to show that we can do a practical combination of OOP and FP. • What got dropped: • Concurrency was relegated to libraries • No tight connection between language and core calculus (fragments were studied in the νObj paper and others.) • What got added: • Native object and class model, Java interop, XML literals. 5
- 6. Why <XML>? I wanted Scala to have a hipster syntax. • Everybody uses [..] for arrays, so we use (..) • Everybody uses <..> for types, so we use [..] • But now we needed to find another use of <..>
- 7. What Makes Scala Scala? Scala is • functional • object-oriented / modular • statically typed • strict • Closest predecessor: OCaml. • Differences: OCaml separates object and module system, Scala unifies them • OCaml uses Hindley/Milner, Scala subtyping + local type inference.
- 8. 1st Invariant: A Scalable Language • Instead of providing lots of features in the language, have the right abstractions so that they can be provided in libraries. • This has worked quite well so far. • It implicitly trusts programmers and library designers to “do the right thing”, or at least the community to sort things out. 8
- 9. • Scala’s core is its type system. • Most of the advanced types concepts are about flexibility, less so about safety. 2nd Invariant: It’s about the Types 9 Flexibility / Ease of Use Safety Scala Trend in Type-systems Goals of PL design where we’d like it to move
- 10. The Present
- 12. New Environment: Scala.JS Feb 5, 2015: Scala.JS 0.6 released No longer experimental! Fast Great interop with Javascript libraries
- 13. Why does Scala.JS work so well? • Because of @srjd, and the great people who contribute. • But also: It plays to the strengths of Scala • Libraries instead of primitives • Flexible type system • Geared for interoperating with a host language.
- 14. Tool Improvements • Much faster incremental compiler, available in sbt and IDEs • New IDEs • Eclipse IDE 4.0 • IntelliJ 14.0 • Ensime: make the Scala compiler available to help editing
- 15. With: • New debugger • Faster builds • Integrated ScalaDoc
- 16. IntelliJ 14.0 Scala plugin With a cool implicit tracker
- 17. Online Courses
- 18. Session Stats So far: 400’000 inscriptions Success rate ~ 10%
- 19. Where It Is Going?
- 20. Emergence of a platform • Core libraries • Specifications: • Futures • Reactive Streams • Spores • Common vocabulary à Beginnings of a reactive platform, analogous to Java EE
- 21. Java Source Classfiles Native code JDK: The Core of the Java Platform javac JDK JIT
- 22. What Are Classfiles Good For? • Portability across hardware • Portability across OS/s • Interoperability across versions • Place for - optimizations, - analysis, - instrumentation So what is the analogue of the JDK for Scala?
- 23. Picture so far: Scala Source Classfiles + Scala Signatures Native code Scala piggybacks on the JDK scalac JDK JIT
- 24. Challenges for Scala • Binary compatibility • scalac has way more transformations to do than javac. • Compilation schemes change • Many implementation techniques are non-local, require co- compilation of library and client. (e.g. trait composition). • Having to pick a platform • Previously: platform is “The JDK.” • In the future: Which JDK? 7, 8, 9, 10? And what about JS?
- 25. Scala Source TASTY Minimized JavaScript Classfiles Native code Native Code A Scala-Specific Platform packaging tool / linker JDK JIT scalac JS JIT
- 26. • TASTY: Serialized Typed Abstract Syntax Trees • E.g., here’s a TAST for x + 2 The Core Apply Select Ident “+” “x” :: Literal Nil 2 Int (Int)Int Int(2) Int
- 27. Serialized TASTY File Format 27 A reference format for analysis + transformation of Scala code high-level complete detailed.
- 28. def plus2(x: Int) = x + 2 becomes Overall: TASTY trees take up ~25% of classfile size Example: 28 x + 2
- 29. What We Can Do With It Applications: • instrumentation • optimization • code analysis • refactoring Publish once, run everywhere. Automated remapping to solve binary compatibility issues.
- 31. Connect the Dots DOT: A calculus for Papers in FOOL ‘12, OOPSLA ’14. Work on developing a fully expressive machine-verified version is still onoping. dotc: A compiler for a cleaned up version of Scala. lampepfl/dotty on Github 31
- 32. DOT (in FOOL ‘12)
- 33. dotc: Cleaning up Scala XML Literals à String interpolation xml”””<A>this slide</A>””” Procedure Syntax à _ Early initializers à Trait parameters trait 2D(x: Double, y: Double)
- 34. More Simplifications Existential types List[T] forSome { type T}, List[_] Higher-kinded types List à Type with uninstantiated type members List
- 35. expands to Type Parameters as Syntactic Sugar class List[T] { ... } class List { type List$T private type T = List$T }
- 36. expands to General Higher-Kinded Types through Typed Lambdas type Two[T] = (T, T) type Two = Lambda { type hk$Arg type Apply = (hk$arg, hk$arg) }
- 37. expands to General Higher-Kinded Types through Typed Lambdas Two[String] Two { type hk$Arg = String } # Apply
- 38. New Concepts Type unions (T&U) and intersections (T|U) • replace compound types (T with U) • Eliminate potential of blow-up in least upper bound / greatest lower bound operations • Make the type system cleaner and more regular (e.g. intersection, union are commutative). • But pose new challenges for compilation. E.g. class A { def x = 1 } class B { def x = 2 } val ab: A | B = ??? ab.x // which x gets called?
- 39. Status Compiler close to completion Should have an alpha release by ScalaDays Amsterdam Plan to use TASTY for merging dotc and scalac.
- 41. 1. Implicits that compose We already have implicit lambdas implicit x => t implicit transaction => body What about if we also allow implicit function types? implicit Transaction => Result Then we can abstract over implicits: type Transactional[R] = implicit Transaction => R Types like these compose, e.g. type TransactionalIO[R] = Transactional[IO[R]]
- 42. expands to New Rule: If the expected type of an expression E is an implicit function, E is automatically expanded to an implicit closure. def f: Transactional[R] = body def f: Transactional[R] = implicit _: Transaction[R] => body
- 43. 2. Better Treatment of effects So far, purity in Scala is by convention, not by coercion. In that sense, Scala is not a pure functional language. We’d like to explore “scalarly” ways to express effects of functions. Effects can be quite varied, e.g. - Mutation - IO - Exceptions - Null-dereferencing, ... Two essential properties: - they are additive, - they propagate along the call-graph.
- 44. ` “Though Shalt Use Monads for Effects” Monads are cool But for Scala I hope we find something even better. • Monads don’t commute. • Require monad transformers for composition. • I tried to wrap my head around it, but then it exploded.
- 45. use this Idea: Use implicits to model effects as capabilities def f: R throws Exc = ... def f(implicit t: CanThrow[Exc]): R = ... instead of this type throws[R, Exc] = implicit CanThrow[Exc] => R or add this to get back to this!
- 46. In Summary Scala - established functional programming in the mainstream, - showed that a fusion with object-oriented programming is possible and useful, - promoted the adoption of strong static typing, - has lots of enthusiastic users, conference attendees included. Despite it being 10 years out it has few close competitors. 46
- 47. Our Aims • Make the platform more powerful • Make the language simpler • Work on foundations to get to the essence of Scala. Let’s continue to work together to achieve this. Thank You!