4 ms·

Beyond Scala 2.8 - A Roadmap

34 points by fogus 16y ago

scala_hacker 16y ago
It is interesting that he does not mention any plans to fix the several egregious type soundness holes in Scala's type system.
- ltr 16y ago
  This is the first time I've heard this particular criticism of Scala. Could you please describe in a little more detail exactly what problems you believe exist, or link to an article that does?
  - scala_hacker 16y ago
    Consider the following program: trait X { trait A { type T >: Int <: Int } val x : A var n : x.T = 3 } trait Y extends X { trait B { type T >: String <: String } lazy val x : A with B = x n = "foo" } new Y {} I just used this because it is extremely simple and is just the tip of the iceberg. It is possible to exploit this in much more interesting ways and dangerous ways, but those are less concise. It is worth noting that this is not just a simple compiler bug, but a deep flaw in the way type members and type composition interact.
    - carterschonwald 16y ago
      what do the :> and :< operators mean in this context, I though they were used for indicating sub/super types?
      - scala_hacker 16y ago
        They place upper and lower bounds on the type member.
    - cageface 16y ago
      This looks slightly contrived. Can you provide an example more likely to crop up in typical usage?
    - supersillyus 16y ago
      I think you and I have different definitions of "extremely simple".
    - mjw 16y ago
      Interesting. Seems this depends on path-dependent types (x.T in the example) ? Do you think it's possible to fix the type system to avoid this without throwing away large parts of it? Is there are a relevant scala trac ticket?
- modersky 16y ago
  That would go under bug fixes. But you could help us by filing tickets on trak. The general issue (type volatility) is well known, but you have discovered a loophole which wasn't.
  - deleted 16y ago
    [deleted]
  - scala_hacker 16y ago
    The bug has already been listed in trac for quite some time now -- that is how I found out about it. However, it is unclear how you can expect to detect conflicting member infos and still retain separate compilation. Still, I look forward to you proving me wrong.
paol 16y ago
Parallel collections are the most interesting development for 2.9. In a nutshell the idea is that collection operations like map, filter, etc can execute in parallel in a way that is transparent to the program. Check out the presentation from Scala Days 2010: http://days2010.scala-lang.org/node/138/140 http://days2010.scala-lang.org/node/138/140
cageface 16y ago
I'm coming to really like the new collections library. It took a little getting used to but now that I'm finding the idiomatic uses it's very nice to work with.
earl 16y ago
If only they would build a plugin that worked. I don't even care between eclipse, intellij, or netbeans -- just one that works. As it is, I can't sell scala when their plugin regularly hard locks eclipse for multiple minutes at a time, generates spurious compiler errors, etc. And our project isn't that big -- 2000 kloc java, 8.3k java files. We're a perfect place for scala given our extant code base, but until the tools work, it's not happening :(
- andrew1 16y ago
  We use Intellij 9.0.3 Community Edition with Scala 2.8 for full time Scala development and have hardly any problems. The biggest complaints I have are that Intellij doesn't recognise that some imports are necessary (although that's probably quite a hard thing to get right for Scala so I can forgive them) and that breakpoints are not 100% reliable (although you get a feel for when they will/won't work). I'd really recommend you try Intellij 9.0.3, it's improved from Intellij 8, and is wildly better than what Eclipse offers.
- BonoboBoner 16y ago
  They are a group of academic people, funded by tax payers money that is supposed to be spent on research only. They cant just do what the market wants, because they have a benchmark, which is the number of published papers - not the rate of adoption of their product.
  - andrew1 16y ago
    That seems a little unfair. Martin Odersky has been pretty clear that he doesn't want Scala to be 'just' an academic language. In his address at Scala Days he talks about this, and about how they are investigating making Scala independent of EPFL, with possible funding from industry. Also, not all the development of Scala is done at EPFL; for example Paul Phillips (one of the key contributors to the compiler) doesn't work there (and isn't an academic so doesn't need to be concerned with publishing papers). On another note, I don't believe that plugins for IDEs should necessarily be contributed by the 'core' Scala team. It makes more sense to me that people closer to the IDE in question are in a better position to write effective plugins. The Intellij plugin was written internally by Intellij and is perfectly usable in my opinion. Interestingly they've made the choice of not using the Scala compiler for syntax highlighting/error marking etc. which (again) in my opinion is a better choice than tieing this into the compiler.

34 points by fogus 16y ago

It is interesting that he does not mention any plans to fix the several egregious type soundness holes in Scala's type system.

ltr 16y ago
This is the first time I've heard this particular criticism of Scala. Could you please describe in a little more detail exactly what problems you believe exist, or link to an article that does?
- scala_hacker 16y ago
  Consider the following program: trait X { trait A { type T >: Int <: Int } val x : A var n : x.T = 3 } trait Y extends X { trait B { type T >: String <: String } lazy val x : A with B = x n = "foo" } new Y {} I just used this because it is extremely simple and is just the tip of the iceberg. It is possible to exploit this in much more interesting ways and dangerous ways, but those are less concise. It is worth noting that this is not just a simple compiler bug, but a deep flaw in the way type members and type composition interact.
  - carterschonwald 16y ago
    what do the :> and :< operators mean in this context, I though they were used for indicating sub/super types?
    - scala_hacker 16y ago
      They place upper and lower bounds on the type member.
  - cageface 16y ago
    This looks slightly contrived. Can you provide an example more likely to crop up in typical usage?
  - supersillyus 16y ago
    I think you and I have different definitions of "extremely simple".
  - mjw 16y ago
    Interesting. Seems this depends on path-dependent types (x.T in the example) ? Do you think it's possible to fix the type system to avoid this without throwing away large parts of it? Is there are a relevant scala trac ticket?
modersky 16y ago
That would go under bug fixes. But you could help us by filing tickets on trak. The general issue (type volatility) is well known, but you have discovered a loophole which wasn't.
- deleted 16y ago
  [deleted]
- scala_hacker 16y ago
  The bug has already been listed in trac for quite some time now -- that is how I found out about it. However, it is unclear how you can expect to detect conflicting member infos and still retain separate compilation. Still, I look forward to you proving me wrong.

paol 16y ago

Parallel collections are the most interesting development for 2.9. In a nutshell the idea is that collection operations like map, filter, etc can execute in parallel in a way that is transparent to the program. Check out the presentation from Scala Days 2010: http://days2010.scala-lang.org/node/138/140 http://days2010.scala-lang.org/node/138/140

cageface 16y ago

I'm coming to really like the new collections library. It took a little getting used to but now that I'm finding the idiomatic uses it's very nice to work with.

earl 16y ago

If only they would build a plugin that worked. I don't even care between eclipse, intellij, or netbeans -- just one that works. As it is, I can't sell scala when their plugin regularly hard locks eclipse for multiple minutes at a time, generates spurious compiler errors, etc. And our project isn't that big -- 2000 kloc java, 8.3k java files. We're a perfect place for scala given our extant code base, but until the tools work, it's not happening :(

andrew1 16y ago
We use Intellij 9.0.3 Community Edition with Scala 2.8 for full time Scala development and have hardly any problems. The biggest complaints I have are that Intellij doesn't recognise that some imports are necessary (although that's probably quite a hard thing to get right for Scala so I can forgive them) and that breakpoints are not 100% reliable (although you get a feel for when they will/won't work). I'd really recommend you try Intellij 9.0.3, it's improved from Intellij 8, and is wildly better than what Eclipse offers.
BonoboBoner 16y ago
They are a group of academic people, funded by tax payers money that is supposed to be spent on research only. They cant just do what the market wants, because they have a benchmark, which is the number of published papers - not the rate of adoption of their product.
- andrew1 16y ago
  That seems a little unfair. Martin Odersky has been pretty clear that he doesn't want Scala to be 'just' an academic language. In his address at Scala Days he talks about this, and about how they are investigating making Scala independent of EPFL, with possible funding from industry. Also, not all the development of Scala is done at EPFL; for example Paul Phillips (one of the key contributors to the compiler) doesn't work there (and isn't an academic so doesn't need to be concerned with publishing papers). On another note, I don't believe that plugins for IDEs should necessarily be contributed by the 'core' Scala team. It makes more sense to me that people closer to the IDE in question are in a better position to write effective plugins. The Intellij plugin was written internally by Intellij and is perfectly usable in my opinion. Interestingly they've made the choice of not using the Scala compiler for syntax highlighting/error marking etc. which (again) in my opinion is a better choice than tieing this into the compiler.