Scala Roadmap (as of April 2012)

Scala Roadmap “A good map always tells you everything except
how to refold it.”

* Scala Improvement Process (SIPs) * Scala 2.10 (shiny!) *
Things pushed to Scala 2.11 * Scala 3.0 and beyond

Scala Improvement Process (SIP)

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

SIP Committee Martin Odersky Paul Philips Josh Suereth Adriaan Moors

And that's pretty much what happened for Scala 2.10 ...

So what's in store for Scala 2.10 ?

String Interpolation (SIP-11)

“Bob is “ + n + ” years old” s“Bob
is $n years old”

“Bob is %2d years old” format n f”$name is $n%2d
years old”

Extensible! xml””” <body> <a href = “some link”> ${linktext} </a>
</body> ””” (and macro-friendly)

And pattern-matching friendly, too. fragment match { case xml””” <body>
<a href = “some link”> $linktext </a> </body> “”” => … // linktext is bound }

Implicit classes (SIP-13)

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)

Value classes (SIP-15) “Performance, performance, performance.”

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!)

class Wrapper(val w: Wrapped) extends AnyVal { def extension1(...) =
… … def extension2(...) = … }

Restrictions * Exactly one parameter (treated as val) * No
members * No initialization statements * No equals() or hashCode() * Top-level or statically reachable

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

* 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)

Type Dynamic (SIP-17) “Static types are great, but sometimes we
would like to do without them.”

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”)

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

“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

* 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.

object languageFeature { trait dynamics trait postfixOps trait reflectiveCalls trait
implicitConversions trait higherKinds trait existentials object experimental { trait macros } }

Examples: import language.experimental.macros import language.{reflectiveCalls, existentials} Or: import language._ //
!!!

Also possible to enable language features in all compiled files
by specifying command line options: scalac -language:implicitConversions -language:higherKinds Or wholesale, scalac -language:_

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

Future and Promises (SIP-14) “[...] redesign of scala.concurrent into a
unified substrate for a variety of parallel frameworks.”

Unify the following implementations: * Scala standard lib * Akka
* Finagle * Scalaz * SFF4S

Other (random) Scala 2.10 Changes

* 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

* 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

* Added collection.mutable.TreeSet * Added collection.concurrent.TrieMap (scalable, thread-safe & lock-free)
* Updated Fork-Join implementation * Miscelaneous collection performance improvements * DelayedInit trait deprecated

* View bounds deprecated (subsumed by implicit params and context
bounds) e.g. def f[A <% B](a: A) = a.bMethod * Virtual pattern matcher (virtpatmat)

Postponed: Uncluttering Scala’s syntax for control structures (SIP-12)

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)

Not Accepted: Source Locations (SIP-19) [ Expected to be easily
implemented using macros ]

Scala 3.0 (and beyond)

Scala has a simple and consistent core ... but ...
some more specialized features are not yet as unified with the rest as they could be.

Ambition for next 2-4 years is to find further simplifications
and unifications.

Goal is for Scala to have an "obvious compact design"

First, stop accusations of it being a complex language.

More importantly, help people writing advanced software systems work with
fewer but more powerful concepts.

Some potential simplifications

Remove XML literals (duh!) New string interpolation scheme allows putting
everything in libraries. Bonus: Swappable implementations

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)

But ... need classes for Java compatibility. Scala needs to
remain a practical programming language, compatible with what Scala currently is.

Potential breakthrough Unify type parameters and abstract type members

The idea is to treat the following two types as
equivalent trait Seq[type Elem] and trait Seq { type Elem }

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)

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.

new HashMap[String, List[Int]] with SynchronizedMap[String, List[Int]] => new HashMap[String, List[Int]]
with SynchronizedMap

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.

“Scala 3 does not have an arrival date. It's not
even sure that it will ever arrive.” – Martin Odersky

THE END. “You’ll learn more about a road by traveling
it than be consulting all the maps in the world.”

Effect System

Scala Roadmap (as of April 2012)

Scala Roadmap (as of April 2012)

More Decks by boia01

Other Decks in Programming

Featured

Transcript