3 ms·

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.

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.