Type Frustrations II : Return of the Erasure

Work is currently sucking up every single scrap of energy I have. Work does this. Sweet, sweet release is on the distant horizon though. In order to not go completely insane, I have been continuing to fiddle with my own stuff, and here's another irritated braindump:

This seems interesting. Where by 'interesting' I mean 'very frustrating'.

I found a lovely little implementation of the simply-typed lambda calculus in the paper "Matching Objects With Patterns". This looked like an interesting way to approach the storage of heterogeneous data for game entities, so here's the bare bones in this context:

case class Var[A]( name: String )

  abstract class Env {
    def apply[A]( v: Var[A] ) : A
    def extend[A]( v: Var[A], x: A ) : Env = new Env {
      def apply[B]( w: Var[B] ) : B = w match {
        case _ : v.type => x
        case _ => Env.this.apply(w)
      }
    }
  }

  object Empty extends Env {
    def apply[A]( v: Var[A] ) : A = error( "not found: "+v.name )
  }

  //use it like this:
  val entity = Empty.extend(Var[Int]("health"),95).extend(Var[String]("desc"),"a wild fnord")
  val entity_desc = entity(Var[String]("desc"))
  

This is easily fiddled with to remove a lot of the boilerplate when extending the Env, but anyway...

It's a little bit odd. The slightly strange v.type is what got me excited; this is the singleton type of v, in Scala parlance. This means it's a type unique to v, equal to another singleton type only if the objects compare equal according to the method eq.

Because Var[A] is a case class (and a very simple one at that), this means that v.type == w.type if the constructor arguments are the same and - my assumption - if the type parameters of the two Vars are also the same. After all, Var[Int] clearly has a different type to Var[String].

Doom.

Enter type erasure. At runtime, all those Var[Int] and Var[String] and Var[Pony] are just plain Var. Singleton types for these now only depend on the constructor arguments, which means stuff like this:

//this should produce a "not found" error:
entity(Var[String]("health"))

java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String

This becomes even more horrible if the code is extended to return an Option, so that rather than producing an error on accessing an undefined variable we simply return None. In this case, the above code returns what appears to be a perfectly valid Some[String], right up until you try to access the contained 'string' and hit the same cast exception but in an entirely arbitrary point in the code, potentially miles from the source of error.

It's so very frustrating that this elegant code doesn't work, simply because a little chunk of information is not present at runtime. Type erasure; it really is the most annoying thing about working with Scala, and I bump into it far more than I would like.

PS: Picked up Clojure again. Maybe I'm completely insane (I am), but I'm tempted to write the game as a sever/client app, with the game logic entirely in Clojure and using Scala for the rendering/IO. That's a lot of extra protocols to implement, and it still has problems, but... this is exactly the kind of thing that is a non-issue in a Lisp.

PPS: I made a half-hearted stab at implementing the Env in Haskell. Yeah, the syntax has entirely leaked out of my head after a mere few months of disuse. It wasn't pretty.