This page is no longer maintained — Please continue to the home page at www.scala-lang.org

signature defenses

No replies
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.

In light of the emerging difficulty of the problem, most recently
demonstrated here:

https://lampsvn.epfl.ch/trac/scala/ticket/4388
"java signature requirements lead to unsoundness in non-covariant
positions"

I step back and say, why do we care about generic signatures? Two
primary reasons that I know of:

1) to make it plausible to use scala from java
2) to not break things in the pursuit of 1)

A third reason is so java reflection can be used, but hopefully that
reason has a shelf life and we will ship a scala reflection library
before too long.

The question is whether we wouldn't be better off pushing the problem
into a java-compatibility layer and suppressing signatures in the
standard distribution in all but the most trivial cases. The reasoning
is that the slightest mistake in the signatures can lead to fatal tool
borkage even for people who are not trying to use java from scala. I'm
thinking we should shield the pure-scala population from these issues,
and I don't see how to do so with confidence in the near term without
applying liquid paper to bytecode.

This may well be a terrible idea, I'm just throwing it out there.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland