Reflecting on the exercise leading up to yesterday's post, one of the things that struck me in the comparison of the .net Framework used from F# and the Java APIs available to Scala/JVM was how much the former got little details right to facilitate working in the web-page embedded context. Take the simple task of getting at the URL query parameters for the page in which the applet is embedded
In Silverlight, in the main
In an applet, where
peer is the
Perhaps this just shows how the old-style Java applet has withered on the vine, while Silverlight as a competitor to Flash has taken on a more aggressive stance for developer acceptance -- but with the decade-plus that Java has under its belt compared with Silverlight's barely more than a year (1.0 not really counting), the comparison is rather disappointing.
A few minutes later
Well, my six month old port of the Scala actors package to pure Scala calling the .Net APIs still blows the compiler up in a Scala 2.8 nightly that's just a few days old. The explosion is in pure Scala code taken directly from the 2.7.5 actors package, and not the Scala-calling-.net replacements I coded of the Java parts of that package:
object Eval$2 symbol = final case
object Eval$2 owner = final object Futures with methods = List(scala.actors.Futures.Eval$2. , scala.actors.Futures.Eva l$2.readResolve, scala.actors.Futures.Eval$2.canEqual, scala.actors.Futures.Eval $2.productElement, scala.actors.Futures.Eval$2.productArity, scala.actors.Future s.Eval$2.productPrefix, scala.actors.Futures.Eval$2.toString, scala.actors.Futur es.Eval$2.productElements, scala.actors.Futures.Eval$2.productIterator) Exception in thread "main" java.lang.RuntimeException: ILGenerator.emit(): Stack underflow in method: public static System.Void scala.actors.Futures$+scala.acto rs.Futures.Eval$2$::.cctor() at ch.epfl.lamp.compiler.msil.emit.ILGenerator.emit(ILGenerator.scala:48 7)
So, still not ready for prime-time.