Friday 16 January 2009

Type Frustrations

Warning: this entry is largely a rant about my own ignorance.

I should have remembered this, but there's a big annoying thing that crops up whenever I try to get overly-generic in Scala.

Type erasure.

My understanding of this is that it's a pain in the arse. It has something to do with brutally discarding useful type information at runtime, such that List[Int] has the type List (or possibly List[Object]). Never mind that List is not even a type, it's a type constructor, some combination of the JVM and the writhing tentacles of an entire herd of shoggoths1 renders it a nigh-useless blob. Dark magic makes it work perfectly when all manipulations are done at compile time, but just try pattern matching or reflection with it...

What this means is that the following code will not compile:

//NB: Will not compile, type of [A] is unchecked due to erasure
def propTest( p: Property ) = p match {
case li:ListProperty[Int] => println( li.value.toString )
case lf:ListProperty[Float] => println( lf.value.mkString(":") )
case _ => println( "unknown property: "+p.toString )
}


Of course, this non-compilation is slightly less annoying than when you only try to pattern-match against a single instance of a parametrised type. In this case the compiler will emit a warning, but still compile to (apparently) working bytecode. If we dispense with the ListProperty[Float] case, the above will compile, li will match any ListProperty, and ClassCastExceptions or similar evil will almost certainly ensue.

Ignoring compilation warnings is (as we all know) incredibly dumb, and re-running compilation with the -unchecked flag will produce more helpful messages about what exactly is completely broken. It's still somewhat vexing that this compiles at all, when the chances of it doing anything useful are effectively zero.

I guess I can't complain overmuch, pattern matching against arbitrary type constructors appears to be something Haskell chokes on too, although with less smelly default behaviour and a different reason. I'm not sure how much of this is down to my downright shoddy understanding of type systems in both languages, so I'll be fiddling with this a lot more. In the interim, without some method for defining simple container properties, including type checking and pattern matching against them, the 'property bag' model appears dead in the water for my chosen implementation language.

As I said before: arse.

1What the hell is the plural of 'shoggoth'? For that matter, what's the collective noun for 'em?

3 comments:

Anonymous said...

There aren't that many collective nouns, try 'group'.

Words that are not collective nouns:
stripe
thunder
etc.
Just because someone invented a list doesn't make them collective nouns.

Snut said...

(a) That's a very boring way to refer to shoggothen
(b) Herd, gaggle, pod etc. are all collective nouns, if rather specific and limited ones. At least, such I was taught, and Infallible, Omniscient Wikipedia agrees with me.
(c) I shall now refer to them as a Great Squirming of Shoggothen.

fhtagn said...

Well, if Stross can be considered canon, the plural is Shoggothim, in a bastard mixture of of Lovecraft and Hebrew. And, frankly, that in itself suggests that it should be considered canon.