scala typeclass extension/generalization initialization - scala

Question

I ran into a weird and puzzling NPE. Consider the following usecase:
Writing a generic algorithm (binary search in my case), where you'd want to generalize the type, but need some extras.
e.g: maybe you want to cut a range in half, and you need a generic half or two "consts".
Integral typeclass is not enough, since it only offers one and zero, so I came up with:
trait IntegralConsts[N] {
val tc: Integral[N]
val two = tc.plus(tc.one,tc.one)
val four = tc.plus(two,two)
}
object IntegralConsts {
implicit def consts[N : Integral] = new IntegralConsts[N] {
override val tc = implicitly[Integral[N]]
}
}
and used it as follows:
def binRangeSearch[N : IntegralConsts]( /* irrelevant args */ ) = {
val consts = implicitly[IntegralConsts[N]]
val math = consts.tc
// some irrelevant logic, which contain expressions like:
val halfRange = math.quot(range, consts.two)
// ...
}
In runtime, this throws a puzzling NullPointerException on this line: val two = tc.plus(tc.one,tc.one).
As a workaround, I just added lazy to the typeclass' vals, and it all worked out:
trait IntegralConsts[N] {
val tc: Integral[N]
lazy val two = tc.plus(tc.one,tc.one)
lazy val four = tc.plus(two,two)
}
But I would want to know why I got this weird NPE. Initialization order should be known, and tc should have already been instantiated when reaching val two ...

Answer 1

Initialization order should be known, and tc should have already been
instantiated when reaching val two
Not according to the specification. What really happens is that while constructing the anonymous class, first IntegralConsts[T] will be initialized, and only then will the overriding of tc be evacuated in the derived anon class, which is why you're experiencing the NullPointerException.
The specification section §5.1 (Templates) says:
Template Evaluation
Consider a template sc with mt1 with mtn { stats }.
If this is the template of a trait then its mixin-evaluation consists of an evaluation of the statement sequence stats.
If this is not a template of a trait, then its evaluation consists of the following steps:
First, the superclass constructor sc is evaluated.
Then, all base classes in the template's linearization up to the template's superclass denoted by sc are mixin-evaluated. Mixin-evaluation happens in reverse order of occurrence in the linearization.
Finally the statement sequence stats is evaluated.
We can verify this by looking at the compiled code with -Xprint:typer:
final class $anon extends AnyRef with IntegralConsts[N] {
def <init>(): <$anon: IntegralConsts[N]> = {
$anon.super.<init>();
()
};
private[this] val tc: Integral[N] = scala.Predef.implicitly[Integral[N]](evidence$1);
override <stable> <accessor> def tc: Integral[N] = $anon.this.tc
};
We see that first, super.<init> is invoked, and only then is the val tc initialized.
Adding to that, lets look at "Why is my abstract or overridden val null?":
A ‘strict’ or ‘eager’ val is one which is not marked lazy.
In the absence of “early definitions” (see below), initialization of
strict vals is done in the following order:
Superclasses are fully initialized before subclasses.
Otherwise, in declaration order.
Naturally when a val is overridden, it is not initialized more than once ... This is not the case: an overridden val will appear to be null during the construction of superclasses, as will an abstract val.
We can also verify this by passing the -Xcheckinit flag to scalac:
> set scalacOptions := Seq("-Xcheckinit")
[info] Defining *:scalacOptions
[info] The new value will be used by compile:scalacOptions
[info] Reapplying settings...
[info] Set current project to root (in build file:/C:/)
> console
> :pa // paste code here
defined trait IntegralConsts
defined module IntegralConsts
binRangeSearch: [N](range: N)(implicit evidence$2: IntegralConsts[N])Unit
scala> binRangeSearch(100)
scala.UninitializedFieldError: Uninitialized field: <console>: 16
at IntegralConsts$$anon$1.tc(<console>:16)
at IntegralConsts$class.$init$(<console>:9)
at IntegralConsts$$anon$1.<init>(<console>:15)
at IntegralConsts$.consts(<console>:15)
at .<init>(<console>:10)
at .<clinit>(<console>)
at .<init>(<console>:7)
at .<clinit>(<console>)
As you've noted, since this is an anonymous class, adding the lazy to the definition avoids the initialization quirk altogether. An alternative would be to use early definition:
object IntegralConsts {
implicit def consts[N : Integral] = new {
override val tc = implicitly[Integral[N]]
} with IntegralConsts[N]
}