jvm-languages | 易学教程

Strange type conversion from List[(Char, Char)] to Object

阅读更多关于 Strange type conversion from List[(Char, Char)] to Object

问题 I have a recursive function count in Scala 2.9.2 that looks like this def count(traces: Seq[(Char, Char)], acc: (TP, TN, FP, FN)): (TP, TN, FP, FN) = { val (tp, tn, fp, fn) = acc traces match { case Nil => acc case ('(', '(')::rest => count(rest, (tp + 1, tn, fp, fn)) case (')', ')')::rest => count(rest, (tp + 1, tn, fp, fn)) case ('(', ')')::rest => count(rest, (tp, tn + 1, fp, fn)) // ... exhaustive set of cases ... } } On input Seq(('(', '(')) the function throws the following MatchError :

J2ME development without Java?

阅读更多关于 J2ME development without Java?

问题 I'm making my first foray into the J2ME world. I'd prefer to use a functional language to do the development. Scala used to have CLDC support, but it's no longer maintained. Bigloo seems to have disappeared. Interpreters (such as Jython) are a no-go, since J2ME apps have to be small (at least, mine has to be). I would like to know of anyone who has been able to use another JVM language to build J2ME apps. 回答1: Running a different language on top of CLDC might be cool but the devices are

Recursive overloading semantics in the Scala REPL - JVM languages

阅读更多关于 Recursive overloading semantics in the Scala REPL - JVM languages

问题 Using Scala's command line REPL: def foo(x: Int): Unit = {} def foo(x: String): Unit = {println(foo(2))} gives error: type mismatch; found: Int(2) required: String It seems that you can't define overloaded recursive methods in the REPL. I thought this was a bug in the Scala REPL and filed it, but it was almost instantly closed with "wontfix: I don't see any way this could be supported given the semantics of the interpreter, because these two methods must to be compiled together." He

Are Kotlin's reified types incorrect for primitives on the JVM?

阅读更多关于 Are Kotlin's reified types incorrect for primitives on the JVM?

问题 If a Kotlin function invocation reifies a primitive, say Int , the 'passed' class is that for the boxed primitive, not the unboxed version. inline fun <reified T> reify() = T::class @Test fun reified_type_doesnt_match_for_primitive() { assertNotEquals(Int::class, reify<Int>()) assertNotEquals(Int::class.java, reify<Int>().java) assertNotEquals<Any>(Int::class, reify<Int?>()) val nullableInt: Int? = 42 assertNotEquals(nullableInt!!.javaClass.kotlin, reify<Int>()) assertEquals<Any>(java.lang

Code generation from three address code to JVM bytecode

阅读更多关于 Code generation from three address code to JVM bytecode

问题 I'm working on the byte code compiler for Renjin (R for the JVM) and am experimenting with translating our intermediate three address code (TAC) representation to byte code. All the textbooks on compilers that I've consulted discuss register allocation during code generation, but I haven't been able to find any resources for code generation on stack-based virtual machines like the JVM. Simple TAC instructions are trivial to translate into bytecode, but I get a bit lost when temporaries are

Scala generics - why I can't create parametrised object inside generic class?

阅读更多关于 Scala generics - why I can't create parametrised object inside generic class?

问题 I'm currently learning scala. Why this code doesn't work: class GenClass[T](var d : T) { var elems: List[T] = Nil def dosom(x: T) = { var y = new T() y } } I get: error: class type required but T found in place of var y - new T() Is it because type erasing from java? Is there any way to solve this - create variable of type T inside generic function? 回答1: have a look at this question, there's an example of a factory: How to instantiate an instance of type represented by type parameter in Scala

Are Kotlin's reified types incorrect for primitives on the JVM?

阅读更多关于 Are Kotlin's reified types incorrect for primitives on the JVM?

If a Kotlin function invocation reifies a primitive, say Int , the 'passed' class is that for the boxed primitive, not the unboxed version. inline fun <reified T> reify() = T::class @Test fun reified_type_doesnt_match_for_primitive() { assertNotEquals(Int::class, reify<Int>()) assertNotEquals(Int::class.java, reify<Int>().java) assertNotEquals<Any>(Int::class, reify<Int?>()) val nullableInt: Int? = 42 assertNotEquals(nullableInt!!.javaClass.kotlin, reify<Int>()) assertEquals<Any>(java.lang.Integer::class.java, reify<Int>().java) } @Test fun reified_type_matches_for_class() { assertEquals

What compromises Scala made to run on JVM?

阅读更多关于 What compromises Scala made to run on JVM?

问题 Scala is a wonderful language, but I wonder how could be improved if it had it's own runtime? I.e. what design choices were made because of JVM choice? 回答1: This article is a discussion with Martin Odersky (Scala's creator) and includes the compromises that were made in Scala for compatibility with Java. The article mentions: Static overloading of methods Having both traits and classes Inclusion of null pointers. 回答2: The two most important compromises I know about are: type erasure (

Adding default package imports

阅读更多关于 Adding default package imports

问题 In Java, Scala, or generally any JVM language, there is a set of packages that is imported by default. Java, for instance, automatically imports java.lang , you don't need to do it in your Java code file. Now I don't know which component takes care of this exactly (the compiler? the JVM?), but is there any way to have additional packages or even classes imported by default? Say you have a package defining a set of utility functions you use throughout your project (an example could be scala

What compromises Scala made to run on JVM?

阅读更多关于 What compromises Scala made to run on JVM?

Scala is a wonderful language, but I wonder how could be improved if it had it's own runtime? I.e. what design choices were made because of JVM choice? This article is a discussion with Martin Odersky (Scala's creator) and includes the compromises that were made in Scala for compatibility with Java. The article mentions: Static overloading of methods Having both traits and classes Inclusion of null pointers. VonC The two most important compromises I know about are: type erasure (" reflecting on Type "): It has to manage a Manifest to get around the Java compilation (independent of the JVM, for