25

A while ago I read about Scala for LLVM and I kept wondering which things in the Scala language/specification/library) only exist to make the JVM happy or improve interop with Java.

Considering that running Scala on the LLVM provides much more freedoms and the plan is port the language (and not the whole Java ecosystem around it) which features won't make sense there?

Guidance: I'm wondering about things like Object#finalize, the monitor stuff (notify, wait), clone vs. Cloneable, no 64-bit array indices, collection sizes limited to 32-bit, java.lang.String, Java reflection, ...

soc
  • 27,983
  • 20
  • 111
  • 215
  • This is a great question. In fact, I've been thinking recently around this very area in trying to imagine how having Java/JVM compatibility being primary might be currently thwarting attempts to create an as good as or better implementation on .NET's CLR. For example, it sure feels wrong to have equals and hashcode on the root class (and I'm not even fond of toString being there). It feels too Java (and even C#) library specific. – chaotic3quilibrium Jun 06 '11 at 23:41
  • If those people who closed the question would have given me some hint before voting I could have improved my question ... *sigh* – soc Jun 11 '11 at 20:27
  • @bmargulies: and bmargulies is at it once again. +22 upvotes, 3 favorited. A very real question with **OUTSTANDING** answers and bmargulies is voting to close again. I'm sick of SO. – SyntaxT3rr0r Jun 15 '11 at 08:09
  • Please re-open ! that's definitely a real question. – Alois Cochard Jun 17 '11 at 14:20

5 Answers5

21

null, null, null, and null

Bill
  • 44,502
  • 24
  • 122
  • 213
  • 2
    If `null` were removed, what would `var x: List[Int] = _` be? Another example: if the constructor of a parent class references a subclass field, what value should be returned? Maybe accessing uninitialized fields should throw an exception? But that might incur a performance penalty. – Kipton Barros Jun 06 '11 at 19:58
  • 3
    It would force code to never leave anything uninitialized. This might be inconvenient, but it would improve robustness. You could redefine "x" to be `var x: Option[List[Int]] = None`. – Dean Wampler Jun 06 '11 at 20:07
  • @Kipton: The problem is that null is a subtype of _every_ type (a requirement for Java interop), so "val x: String = null; x.length" sails right past the compiler. The problem isn't that variables are allowed to have no value; just as long as that lack of value has a separate type. The implementation would probably use scala.Option, but I could also imagine creating something like scala.NullableCell[T] to allow for these cases. null is still allowed in the language, but you would have to do "val y: NullableCell[String] = Null" and then y.length would fail to compile – Bill Jun 06 '11 at 21:46
  • You'd have to pattern-match on y or call an accessor method to get at the value. You still have to do null checks but only in places where you expect null. As it stands, in a typical language, any reference passed in as an argument or received from a method could, strictly speaking, be either of its declared type or of type null. It's ugly. – Bill Jun 06 '11 at 21:47
  • @Dean: My point is that when the constructor of the super-class is executing, the constructor of the sub-class hasn't run yet, and the sub-class fields are necessarily uninitialized. But they can be accessed at this time; for example, the super-class constructor could call a virtual method that the sub-class overrides. This is one way that `null` shows up (it's usually a bug, of course). – Kipton Barros Jun 07 '11 at 05:13
  • 4
    @Kipton: Seriously, null is a gaping hole in the type system. The points you mention may lead to some inconveniences, but this is nothing compared with the evil powers that inhabit the null reference: Every null reference is a little time bomb, thrown somewhere into the system, and blowing up somewhere else. It is an imposter pretending to be every object you want, and it will betray you, as it isn't. – Landei Jun 07 '11 at 06:27
  • @Landei: Please understand that I'm not arguing in favor of `null`. I'm just pointing out how `null` can appear against our best wishes, in the current Scala language. – Kipton Barros Jun 07 '11 at 06:31
  • Is `null` a bug? I thought it was a feature :) – Jus12 Jun 07 '11 at 13:20
  • @Landei: +1 to your comment... That is why I'm using *@NotNull* basically everywhere in my code. Trespassing fails instantly and, anyway, IntelliJ IDEA warns in real-time about *@NotNull* violations. – SyntaxT3rr0r Jun 15 '11 at 08:13
19

Type erasure. Having every object have a monitor reference (a horrible Java mis-feature).

Dave Griffith
  • 20,435
  • 3
  • 55
  • 76
  • 1
    +1. My understanding is that existential types exist to support erasure, so that could go. – Dean Wampler Jun 06 '11 at 20:09
  • 1
    Well, to be precise, existential types support Java wildcard types, which were necessary to support backwards compatability with pre-JDK1.5 libraries, which is also why we have type-erasure in the JVM. So yeah, they could go too. – Dave Griffith Jun 06 '11 at 22:12
  • 1
    @Dean Yes and no. Existential types are useful for other stuff too -- I have seen it now and then with high order types. – Daniel C. Sobral Jun 06 '11 at 22:59
  • Right - Haskell, which has no JVM constraints to work around, makes heavy use of existentials. – Bill Jun 07 '11 at 02:19
  • 1
    type-erasure is the single worst handicap of Scala due to JVM. – Jus12 Jun 07 '11 at 07:58
  • Hey, guess who else has type erasure: Haskell! And all the MLs. http://groups.google.com/group/scala-user/msg/44458410d34d2038 – Alex Cruise Jun 07 '11 at 17:27
  • @Dave, *Having every object have a monitor reference (a horrible Java mis-feature)* Objects in virtually any JVM do NOT have a monitor reference unless needed (i.e. the monitor changes hands). Even locked by a single thread does not result into a monitor inflation. You can read how biased locking is implemented. – bestsss Jun 15 '11 at 07:43
  • The mis-feature of monitors on every object isn't the implementation, but the specification. Adding a brittle and weak concurrency construct to every object bought little but confusion – Dave Griffith Jun 22 '11 at 01:25
11

The AnyVal type branch could burn in eternal hell fire. Arrays could be implemented in a sane way (okay, the ugliness is hidden pretty well now), same for reified types. The methods clone, hashCode and toString could go into type classes where they belong. Currying could be implemented without multiple arg lists. Type inference and type level programming could be improved.

Landei
  • 54,104
  • 13
  • 100
  • 195
  • How could the AnyVal things handled differently? – soc Jun 06 '11 at 21:27
  • There are languages that hide the primitive/Object distinction and boxing/unboxing behavior completely. – Landei Jun 07 '11 at 06:18
  • +1 to your answer but... Being one of the very selected few to do number crunching professionally under Java, I'm not sure I'd like a language hiding the boxing/unboxing completely. At least Java is sufficiently transparent when it comes to that (mostly lame and pathetic) boxing/unboxing that I can still **force** it to work with primitives. A language where you cannot force the use of primitives is unsuitable for number crunching. Can you both hide completely the behavior and yet be useful in numeric intensive apps? (honest question) – SyntaxT3rr0r Jun 15 '11 at 08:16
  • @SyntaxT3rr0r: I think this is no problem: Scala has already the `@specialized` annotation, which is working really smooth. And if all classes you work with are correctly specialized (and no things like `implicit` magic are used), there is no reason for the compiler to box a primitive. – Landei Jun 15 '11 at 13:02
3

I hope that a Scala port to LLVM include user-defined value types (like struct types in CLR). The issue is avoiding heap allocation. For example, in scientific computing there is a need for abstractions like arrays of complex numbers, but heap allocating each complex number is too costly (in terms of space and cache misses).

Edit: Maybe the JVM will get value types too. John Rose, a JVM engineer, discusses how value types might be added. There are recent rumors that Oracle plans to add value types for better support of high performance computing.

Community
  • 1
  • 1
Kipton Barros
  • 21,002
  • 4
  • 67
  • 80
  • You can surely allocate stuff on stack (via 'alloca') instruction and then various optimization passes can promote the stuff for you to registers if this will be doable / profitable. – Anton Korobeynikov Jun 07 '11 at 06:05
  • I'm hoping that this feature will be available in the Scala port to LLVM. – Kipton Barros Jun 07 '11 at 06:23
  • There's good reasons to avoid stack allocation too; it's too damn easy to run out of stack (by comparison with the heap) and the results are “fascinating”. – Donal Fellows Jun 07 '11 at 15:11
-8

Syntax, mostly to not scare away existing java developers.

And entire "let's marry objects with functional programming, because java works only with objects".

Without the need to integrate with existing OO libraries there would be no need to castrate type inference, to make an ugly kludge in form of case classes to support pattern matching.

Heck if you look at it, without JVM there would be no Scala, because most of the compromises simply do not make sense if taken out of context of seamless integration with java world.

Vagif Verdi
  • 4,816
  • 1
  • 26
  • 31
  • 6
    Odersky's express intent with Scala was to implement a hybrid Object-Functional language. So, I don't think objects would be removed. – Dean Wampler Jun 06 '11 at 20:08
  • Sure, but there's ocaml with objects and full blown HM type inference. Odersky had to make compromises precisely because of particular OO system on top of which scala supposed to be run. – Vagif Verdi Jun 06 '11 at 20:25
  • 1
    Sorry, but coming up with OCaml here is laughable. The OO part of OCaml should be considered a April 1st prank gone wrong. – soc Jun 06 '11 at 21:15
  • 5
    This is a very silly post. Odersky explicitly intended to unify objects and functional programming. If he just wanted to target the JVM, he could have done whatever he wanted and had it compile to JVM bytecode. The OO is not in the language just because it's implemented atop the JVM... – Bill Jun 06 '11 at 21:54