Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Scala Days San Francisco

•Download as PPT, PDF•
•

- Scala originated from Martin Odersky's work on functional programming languages like OCaml in the 1980s and 1990s. It was designed to combine object-oriented and functional programming in a practical way. - Key aspects of Scala include being statically typed while also being flexible, its unified object and module system, and treating libraries as primary over language features. - Scala has grown into an large ecosystem centered around the JVM and also targets JavaScript via Scala.js. Tooling continues to improve with faster compilers and new IDE support. - Future work includes establishing TASTY as a portable intermediate representation, connecting Scala to formal foundations through the DOT calculus, and exploring new type

1 of 48

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

4

Now Seriously...

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

12

12 An Emergent Ecosystem Scala Akka Play Slick Spark JVM Kafka Mesos Chisel scalaz cats scaldin g ScalaCheck scodec Specs squeryl Samza Finagle ScalaTe st shapele sssbt Lift BlueEyesscalatra JS ADAM

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.

31

Language and Foundations

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.

41

Plans for Exploration

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!

More Related Content

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
  • 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
  • 17. IntelliJ 14.0 Scala plugin With a cool implicit tracker
  • 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!