Scala Roadmap (as of April 2012)

A Bizo-internal presentation made on the state of Scala and a completely unofficial roadmap (as of April 2012) which was more a brain-dump of everything I had noted was happening in Scala-land at the time.

2. Scala Roadmap “A good map always tells you everything except how to refold it.”
3. * Scala Improvement Process (SIPs) * Scala 2.10 (shiny!) * Things pushed to Scala 2.11 * Scala 3.0 and beyond
4. Scala Improvement Process (SIP)
5. Process * Send your idea(s) and discuss on scala-debate@ mailing list. * If it's popular enough, write a SIP document + send pull request * SIP committee may accept SIP and attribute it a number. * Implement it! * At major Scala release, committed will accept / delay / reject
6. SIP Committee Martin Odersky Paul Philips Josh Suereth Adriaan Moors
7. And that's pretty much what happened for Scala 2.10 ...
8. So what's in store for Scala 2.10 ?
9. String Interpolation (SIP-11)
10. “Bob is “ + n + ” years old” s“Bob is $n years old”
11. “Bob is %2d years old” format n f”$name is $n%2d years old”
12. Extensible! xml””” <body> <a href = “some link”> ${linktext} </a> </body> ””” (and macro-friendly)
13. And pattern-matching friendly, too. fragment match { case xml””” <body> <a href = “some link”> $linktext </a> </body> “”” => … // linktext is bound }
14. Implicit classes (SIP-13)
15. implicit class RichInt(n: Int) extends Ordered[Int] { def min(m: Int): Int = if (n <= m) n else m ... } /* desugars to ... */ class RichInt(n: Int) extends Ordered[Int] { def min(m: Int): Int = if (n <= m) n else m ... } implicit final def RichInt(n: Int): RichInt = new RichInt(n)
16. Value classes (SIP-15) “Performance, performance, performance.”
17. Value classes get completely inlined (zero overhead compared to external methods) * Inlined implicit wrappers (extension methods) * New numeric classes (e.g. unsigned ints) * Units of measure (ahem!)
18. class Wrapper(val w: Wrapped) extends AnyVal { def extension1(...) = … … def extension2(...) = … }
19. Restrictions * Exactly one parameter (treated as val) * No members * No initialization statements * No equals() or hashCode() * Top-level or statically reachable
20. Self-cleaning Macros (SIP-16) “Unicorns! LOLCats! Rainbows! Bacon! Jet Packs! Fried dough with sugar on top! Possibly the greatest step in computing in the past decade.” – Self-delusional @boia01
21. * Actually in 'Postponed' SIP status * Experimental implementation available in 2.10. * Macros are actually 3 things, + Code reification + Reflection (via mirrors) + Compile-time AST transformation (CATs)
22. Type Dynamic (SIP-17) “Static types are great, but sometimes we would like to do without them.”
23. val foo: Dynamic = … // 4 types of dynamic invocations foo.method[Ts](args...) // foo.applyDynamic[Ts](“method”)(args...) foo.method[Ts](name = expr, …) // foo.applyDynamicNamed[Ts](“method”)(name expr, …) → foo.method = expr // foo.updateDynamic(“method”)(expr) foo.method // foo.selectDynamic(“method”)
24. Modularizing Language Features (SIP-18) “The curse of a very powerful and regular language is that it provides no barriers against over-abstraction.” – Martin Odersky
25. “The big problem with this proposal is that it threatens to add a bunch of boilerplate to every single existing Scala file, program and REPL session.” – Rex Kerr
26. * Scheme where some of the more advanced and contentious language features have to be enabled explicitly; * Typically using an import from a new language enumeration object. * Depending on feature, may be required at the definition site or usage site.
27. object languageFeature { trait dynamics trait postfixOps trait reflectiveCalls trait implicitConversions trait higherKinds trait existentials object experimental { trait macros } }
28. Examples: import language.experimental.macros import language.{reflectiveCalls, existentials} Or: import language._ // !!!
29. Also possible to enable language features in all compiled files by specifying command line options: scalac -language:implicitConversions -language:higherKinds Or wholesale, scalac -language:_
30. Possible future uses: * language.future to control features to be introduced in future releases * language.deprecated to control features no longer officially supported * language.plugin to control plugin activation
31. Future and Promises (SIP-14) “[...] redesign of scala.concurrent into a unified substrate for a variety of parallel frameworks.”
32. Unify the following implementations: * Scala standard lib * Akka * Finagle * Scalaz * SFF4S
33. Other (random) Scala 2.10 Changes
34. * No more ScalaObject trait * Floating point and octal literal syntax deprecated * Type arguments don't need a dot anymore (e.g. foo asInstanceOf[Int]) * Optimized for loops (Range#foreach) * Runtime compiler toolbox
35. * Separated scala actors from the main library jar * Scala actors deprecated (replaced by Akka actors after 2.10) * scala.dbc package removed. * Added ??? and NotImplementedError e.g. def fib = ??? * Reduced size of PartialFunctions
36. * Added collection.mutable.TreeSet * Added collection.concurrent.TrieMap (scalable, thread-safe & lock-free) * Updated Fork-Join implementation * Miscelaneous collection performance improvements * DelayedInit trait deprecated
37. * View bounds deprecated (subsumed by implicit params and context bounds) e.g. def f[A <% B](a: A) = a.bMethod * Virtual pattern matcher (virtpatmat)
38. Postponed: Uncluttering Scala’s syntax for control structures (SIP-12)
39. Examples if x < y then x else y while x >= y do x /= 2 for x <- 1 to 10; y <- 1 to 10 do println(x * y) for x <- 0 until N y <- 0 until N if isPrime(x + y) yield (x, y)
40. Not Accepted: Source Locations (SIP-19) [ Expected to be easily implemented using macros ]
41. Scala 3.0 (and beyond)
42. Scala has a simple and consistent core ... but ... some more specialized features are not yet as unified with the rest as they could be.
43. Ambition for next 2-4 years is to find further simplifications and unifications.
44. Goal is for Scala to have an "obvious compact design"
45. First, stop accusations of it being a complex language.
46. More importantly, help people writing advanced software systems work with fewer but more powerful concepts.
47. Some potential simplifications
48. Remove XML literals (duh!) New string interpolation scheme allows putting everything in libraries. Bonus: Swappable implementations
49. Simplify Type System (re-duh!) “Ideally, Scala's types will be built from just traits, mixin composition, refinements, and paths, and nothing else.” – Martin Odersky (talking about dependent-object type formalism)
50. But ... need classes for Java compatibility. Scala needs to remain a practical programming language, compatible with what Scala currently is.
51. Potential breakthrough Unify type parameters and abstract type members
52. The idea is to treat the following two types as equivalent trait Seq[type Elem] and trait Seq { type Elem }
53. The definition trait Seq[Elem] could still be kept and be interpreted as a type that has an inaccessible member Elem, similar to the distinction between class C(x: T) and class C(val x: T)
54. The big simplifications are then: (1) Any type can be written without its parameters. (2) Any type that has abstract type members can be retroactively parameterized. (3) Type parameters can be unified by name.
55. new HashMap[String, List[Int]] with SynchronizedMap[String, List[Int]] => new HashMap[String, List[Int]] with SynchronizedMap
56. Gains - eliminate two classes of types - more expressive power through unification of concepts - avoid unnecessary repetition of parameters in mixin compositions and extends clauses - strengthen the analogies between type parameters and value parameters.
57. “Scala 3 does not have an arrival date. It's not even sure that it will ever arrive.” – Martin Odersky
58. THE END. “You’ll learn more about a road by traveling it than be consulting all the maps in the world.”
59. Effect System