## Even more modules in Scala

In response to Rossberg's challenge to encode the following:

``` signature S =
sig
structure A : sig type t; val x : t end
val f : A.t -> int
end
structure M =
struct
structure A = struct type t = int; val x = 666 end
fun f x = x
end
structure N = M :> S
```

In Scala, the above becomes:

``` type S = {
val A: { type T; val x: T }
def f(arg: A.T): Int
}
val M = new {
val A = new { type T = Int; val x = 666 }
def f(arg: Int) = arg
}
val N = M : S
```

And using

`N.f`
on
`N.A.x`
is even well-typed, but still encounters the same problems with evaluation I mentioned earlier. And yes, the type
`N.A.T`
is hidden:

``` scala> val x : Int = M.A.x
x: Int = 666
scala> val x : Int = N.A.x
<console>:7: error: type mismatch;
found   : N.A.T
required: Int
val x : Int = N.A.x
^
scala> val x : N.A.T = 42
<console>:7: error: type mismatch;
found   : Int(42)
required: N.A.T
val x : N.A.T = 42
^
```

As for how Scala, solves the double vision problem, I would look at the work on νObj, and the forthcoming paper on Featherweight Scala.

Update: Looking more closely at the definition of "double vision" as defined by Dreyer, the Scala implementation cannot currently handle his motivating example. I will need to think about how the example works in Featherweight Scala, which to my knowledge shouldn't have a problem with at least defining the type signatures. I think the short answer is that νObj and Featherweight Scala (the non-algorithmic version) solve the problem in a vacuous fashion, as the type checking problem for them is undecidable. Scala proper possibly could resolve the problem by using a less restrictive cycle detection algorithm.