Even more modules in Scala

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

  1.  
  2. signature S =
  3. sig
  4. structure A : sig type t; val x : t end
  5. val f : A.t -> int
  6. end
  7.  
  8. structure M =
  9. struct
  10. structure A = struct type t = int; val x = 666 end
  11. fun f x = x
  12. end
  13.  
  14. structure N = M :> S
  15.  

In Scala, the above becomes:

  1.  
  2. type S = {
  3. val A: { type T; val x: T }
  4. def f(arg: A.T): Int
  5. }
  6.  
  7. val M = new {
  8. val A = new { type T = Int; val x = 666 }
  9. def f(arg: Int) = arg
  10. }
  11.  
  12. val N = M : S
  13.  

And using

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

  1.  
  2. scala> val x : Int = M.A.x
  3. x: Int = 666
  4. scala> val x : Int = N.A.x
  5. <console>:7: error: type mismatch;
  6. found : N.A.T
  7. required: Int
  8. val x : Int = N.A.x
  9. ^
  10.  
  11. scala> val x : N.A.T = 42
  12. <console>:7: error: type mismatch;
  13. found : Int(42)
  14. required: N.A.T
  15. val x : N.A.T = 42
  16. ^
  17.  

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.

Leave a Comment