## 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

on

N.f

is even well-typed, but still encounters the same problems with evaluation I mentioned earlier. And yes, the type

N.A.x

is hidden:

N.A.T

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.