![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/scaladayssf-150316213819-conversion-gate01/85/Scala-Days-San-Francisco-7-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/scaladayssf-150316213819-conversion-gate01/85/Scala-Days-San-Francisco-35-320.jpg)
![expands toexpands toexpands toexpands to
Type Parameters as Syntactic Sugar
class List[T] { ... }
class List {
type List$T
private type T = List$T
}](https://image.slidesharecdn.com/scaladayssf-150316213819-conversion-gate01/85/Scala-Days-San-Francisco-36-320.jpg)
![expands toexpands toexpands toexpands 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/scaladayssf-150316213819-conversion-gate01/85/Scala-Days-San-Francisco-37-320.jpg)
![expands toexpands toexpands toexpands to
General Higher-Kinded Types
through Typed Lambdas
Two[String]
Two {
type hk$Arg = String
} # Apply](https://image.slidesharecdn.com/scaladayssf-150316213819-conversion-gate01/85/Scala-Days-San-Francisco-38-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/scaladayssf-150316213819-conversion-gate01/85/Scala-Days-San-Francisco-42-320.jpg)
![expands toexpands toexpands toexpands 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/scaladayssf-150316213819-conversion-gate01/85/Scala-Days-San-Francisco-43-320.jpg)
![use thisuse thisuse thisuse this
Idea: Use implicits to model effects as
capabilities
def f: R throws Exc = ...
def f(implicit t: CanThrow[Exc]): R = ...
instead of thisinstead of thisinstead of thisinstead of this
type throws[R, Exc] =
implicit CanThrow[Exc] => R
or add thisor add thisor add thisor add this
to get back to this!to get back to this!to get back to this!to get back to this!](https://image.slidesharecdn.com/scaladayssf-150316213819-conversion-gate01/85/Scala-Days-San-Francisco-46-320.jpg)
Scala Days San Francisco
- 1. Scala Where It Came From Where It is Going Martin Odersky Scala Days San Francisco
- 2. Scala Where It Came From Martin Odersky Scala Days San Francisco
- 3. “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
- 5. 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 5
- 6. 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. 6
- 7. 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 <..>
- 8. 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.
- 9. 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. 9
- 10. • 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 10 Flexibility / Ease of Use Safety Scala Trend in Type-systems Goals of PL design where we’d like it to move
- 11. The Present
- 13. New Environment: Scala.JS Feb 5, 2015: Scala.JS 0.6 released No longer experimental! Fast Great interop with Javascript libraries
- 14. 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.
- 15. 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
- 16. With: •New debugger •Faster builds •Integrated ScalaDoc
- 17. IntelliJ 14.0 Scala plugin With a cool implicit tracker
- 18. Online Courses
- 19. Session Stats So far: 400’000 inscriptions Success rate ~ 10%
- 20. Where It Is Going?
- 21. Emergence of a platform • Core libraries • Specifications: • Futures • Reactive Streams • Spores • Common vocabulary Beginnings of a reactive platform, analogous to Java EE
- 22. Java Source Classfiles Native code JDK: The Core of the Java Platform javac JDK JIT
- 23. 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?
- 24. Picture so far: Scala Source Classfiles + Scala Signatures Native code Scala piggybacks on the JDK scalac JDK JIT
- 25. 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?
- 26. Scala Source TASTY Minimized JavaScript Classfiles Native code Native Code A Scala-Specific Platform packaging tool / linker JDK JIT scalac JS JIT
- 27. • 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
- 28. Serialized TASTY File Format 28 A reference format for analysis + transformation of Scala code high-level complete detailed.
- 29. def plus2(x: Int) = x + 2 becomes Overall: TASTY trees take up ~25% of classfile size Example: 29 x + 2
- 30. What We Can Do With It Applications: • instrumentation • optimization • code analysis • refactoring Publish once, run everywhere. Automated remapping to solve binary compatibility issues.
- 32. 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 32
- 33. DOT (in FOOL ‘12)
- 34. 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)
- 35. More Simplifications Existential types List[T] forSome { type T}, List[_] Higher-kinded types List Type with uninstantiated type members List
- 36. expands toexpands toexpands toexpands to Type Parameters as Syntactic Sugar class List[T] { ... } class List { type List$T private type T = List$T }
- 37. expands toexpands toexpands toexpands 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) }
- 38. expands toexpands toexpands toexpands to General Higher-Kinded Types through Typed Lambdas Two[String] Two { type hk$Arg = String } # Apply
- 39. 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?
- 40. Status Compiler close to completion Should have an alpha release by ScalaDays Amsterdam Plan to use TASTY for merging dotc and scalac.
- 42. 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]]
- 43. expands toexpands toexpands toexpands 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
- 44. 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.
- 45. ` “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.
- 46. use thisuse thisuse thisuse this Idea: Use implicits to model effects as capabilities def f: R throws Exc = ... def f(implicit t: CanThrow[Exc]): R = ... instead of thisinstead of thisinstead of thisinstead of this type throws[R, Exc] = implicit CanThrow[Exc] => R or add thisor add thisor add thisor add this to get back to this!to get back to this!to get back to this!to get back to this!
- 47. 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. 47
- 48. Our Aims • Make the platform more powerful • Make the language simplier • Work on foundations to get to the essence of Scala. Let’s continue to work together to achieve this. Thank You!