Scala Improvement Proposal: Digressions

As Scala macros will become a major feature in upcoming 2.10 release, we would like to introduce a minor addition improving macros usability and recovering qualified substitutionality* which is otherwise lost in presence of macros.

We propose a syntax for digressions – pieces of code marked for evaluation in the outer scope. Their main purpose is exclusion of a piece of code from macro processing, but they also appear practical in some cases unrelated to macros.

// Proposed syntax:

f {... <} expr {> ...}


// Proposed translation:

lazy val v = expr

f {... v ...}

The proposed syntax would not compromise backward compatibility since the digraphs “<}” and “{>” proposed as opening and closing digression brackets are invalid character combinations in present Scala.

Use cases

[Дорогие товарищи, давайте сюда напридумываем хороших примеров!]

_____
* Qualified substitutionality is a property of pure code that all named vals can be eliminated by substituting their occurrences by their (properly amended) definitions.

Scala Improvement Proposal: Quotations and Implicit Unboxing

Preliminaries

Let's call a polymorphic type F[T] enveloping if it's equipped with eval: F[T] => T and reify: T => F[T] (reify often being a macro) satisfying eval(reify(expression)) = expression and reify(eval(enveloped)) = enveloped.

A typical and motivating example where reify is a macro is Expr[T]. Examples where no macros are involved are Future[T] (with await as eval) and Option[T] (with getOrElse {throw new NoValue()} as eval).

Autounboxing is the following behaviour: whenever a value of the enveloping type F[T] is found where a value of type T is accepted, eval is called implicitly.* In homoiconic lauguages (including Scala), one can consider all written expressions to be initialy of the type Expr[T] and being autounboxed into T by omnious implicit autounboxing rule Expr[T] => T.

Proposal

We propose to introduce an instruction implicit[F] which enables autounboxing for F in its scope and quotation brackets F<[expr]> which temporarily disable autounboxing.

Use cases

Code intensive in futures and promises can be made much more readable by autounboxing. To take an example, one can look at Dataflows in Akka 2.0. This is how their code looks now:

flow {

  z << (x() + y())

  if (v() > u) println("z = " + z())

}

Using autounboxing this can be recast without any unintuitive empty paranthesis:

flow {

  z << x + y

  if (v > u) println("z = " + z)

}

The main purpose of this syntax is however to be understood in course of the scala purification programme, in which all mutable (volatile) values are distinguished on type level.

____
* In the implicit[F]-scope every occurrence of a symbol having or returning type F[T] which is defined outside of this implicit[F]-scope should be processed by eval unless it won't typecheck. Symbols defined inside the scope are to be left alone.
Usual implicit conversions are lazy (i.e. being applied only if the expression won't typecheck otherwise), implicit autounboxing is applied eargerly (evaluation is performed unless the expression wouldn't typecheck).

(no subject)

Есличо, последние два поста — это черновики, предназначенные для обсуждения и улучшения.