This post just makes me wish that we had a real Scala implementation on .NET/Mono. In a lot of ways, Scala seems like a better fit for the CLR than it does for the JVM.

Method definitions in traits would map well to extension methods on interfaces in .NET. You could translate trait methods right back to C# code and never know it was not natively written. No need for ‘$’ in the names. Tools like Visual Studio would show the extension methods as valid methods for any classes deriving from the interface. Very seamless.

It is great that Scala generics are Java generics but both are smoke and mirrors at the JVM level. The CLR supports generics natively at the bytecode level.

Properties are native to the CLR as well so they translate naturally from Scala. Of course, getters and setters seem just as natural in Java.

Of course, operator overloading is allowed on the CLR so you would not need as much of this brilliant but still somewhat ugly operator to alphabetical name translation stuff.

Having interoperability in reverse would be the real treat. It would be great to see my C# interfaces and extension methods map to nice clean Scala traits for example.

My point is not to slam the JVM. It is the real-use in the real world leader after all. Rather, I am simply expressing my Scala envy and thinking out loud what a great language it would be on .NET/Mono.

There is a real overlap in capability between C# and Scala (even the mix of OO and functional) but Scala takes it a little further and seems to suit me better.

Maybe someday Martin will reward me (he threatens to sometimes).

Thanks for the great content.

How to implement the scala List with Java code?
Such as:
def archs (e:Edge) : List[Point] = Nil

How can I transfer it to java code?

https://lampsvn.epfl.ch/trac/scala/ticket/722

I got rid of $tag entirely a couple months ago.

You’re quite right:

daniel@lal ~ $ javap -classpath /usr/local/scala-2.7.3.final/lib/scala-library.jar scala.Function1$class
Compiled from "Function1.scala"
public interface scala.Function1 extends scala.ScalaObject{
    public abstract scala.Function1 andThen(scala.Function1);
    public abstract scala.Function1 compose(scala.Function1);
    public abstract java.lang.String toString();
    public abstract java.lang.Object apply(java.lang.Object);
}

daniel@lal ~ $ javap -classpath /usr/local/scala-2.7.3.final/lib/scala-library.jar scala.ScalaObject
Compiled from "ScalaObject.scala"
public interface scala.ScalaObject{
    public abstract int $tag()       throws java.rmi.RemoteException;
}

daniel@lal ~ $ javap -classpath /usr/local/scala-2.7.3.final/lib/scala-library.jar 'scala.Function1$class'
Compiled from "Function1.scala"
public abstract class scala.Function1$class extends java.lang.Object{
    public static void $init$(scala.Function1);
    public static scala.Function1 andThen(scala.Function1, scala.Function1);
    public static scala.Function1 compose(scala.Function1, scala.Function1);
    public static java.lang.String toString(scala.Function1);
}

I didn’t actually try to compile any of my examples in the comments, which would explain how I missed this. As a general work-around, you can probably just return 0 from $tag and I don’t think that it will cause too many problems. Alternatively, you can compile a real function value in Scala, decompile it and then look at the bytecode source for $tag, see what Scala does in this case.

* Syntax (much more concise than Java)
* Function values (sometimes called “closures”)
* Concise immutability
* Symbolic methods (operator overloading)
* No statics (pure object-orientation)
* A type system which actually works
* Sane generics

I could go on and on, but those are the biggies.

I’m not a fan of the dynamic language trend where all of the magic is done at runtime and nothing maps to real method calls, just lots of metaclass lookup.

Scala doing magic at compile time and then mapping to regular Java constructs under the hood is a welcome change.

I’m currently pining for a language with the same compile-time, “still Java” magic of Scala, but a bit simpler. boojay is really close, I think, but needs to mature beyond a cool hack.