peano class-cast-exception

[Jan Vanek]

After reading the "ambiguous reference to overloaded definition" thread
in scala-user I played with Rex's Peano example (in 2010) where he tries
to achieve what he calls "conditionally abstract". I didn't achieve it
but I found a bug - the example compiles but crashes with
ClassCastException. I did a minimal search for "ClassCastException" in
JIRA but didn't find the exact match. Please have a look.

trait Peano {
type Nat <: NatApi

trait NatApi { this: Nat =>
def succ: Nat

def count(n: Int): Nat = {
if (n < 1) this
else if (n == 1) succ
else count(n - 1).succ
}
}
}

class Peano4A extends Peano {
class Nat(i: Int) extends NatApi {
def succ = new Nat(i + 1)
}
}

class Peano4B extends Peano4A {
class Nat(val s: String, i: Int) extends super.Nat(i) {
// "override" def succ = new Nat("s("+s+")", i + 1)
}
}

def main(args: Array[String]) {
val p4b = new Peano4B
val n0 = new p4b.Nat("0", 0)
val n1 = n0.count(1)
println(n1.s)
}

With regards,
Jan

[Johannes Rudolph]

The problem seems to be that even if `Peano#NatApi.succ` should
enforce that its result type is again of type Nat, this condition
isn't enforced for `Peano4B#Nat` which inherits a `succ` method with
the wrong return type.

Johannes

> --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scala-languag...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[Jan Vanek]

Either that (option 1) or the Nat in Peano4B should not override the *type* Nat declared in Peano and made-concrete in Peano4A (option 2). Note that if you explicitly set the type Nat, you can't override it. You can achieve it through this class-with-the-same-name though, which seems like inconsistency. This is where I have troubles, I don't know which of those 2 options is the right one, and, if it is the 1st one, why is it not inconsistent.

class Peano4A extends Peano {

  type Nat = NatImpl

  class NatImpl(i: Int) extends NatApi {

    def succ = new NatImpl(i + 1)

  }

}

class Peano4B extends Peano4A {

  // override type Nat = NatImpl // impossible

  class NatImpl(val s: String, i: Int) extends super.NatImpl(i) {

    override def succ = new NatImpl("s("+s+")", i + 1)

  }

}

def main(args: Array[String]) {

  val p4b = new Peano4B

  val n0 = new p4b.NatImpl("0", 0)

  val n1 = n0.count(1)

  // println(n1.s) // n1 is p4b.Nat = Peano4A#NatImpl

}

[Paul Phillips]

Perhaps https://issues.scala-lang.org/browse/SI-7278 is what you're looking for.

[Jan Vanek]

I remember, that was the one where I didn't control myself and said "import future.dotty". But as AM said, in dotty this (your example with inner class E) would not be possible in that form (because those Es are not related, and dotty would prohibit). Which is why I think MO said "I'd argue about that", btw. 

But in my example the inner classes Nat in Peano4A/4B are in proper relationship. So it seems to be a different case, well, I hope I didn't overlook something, correct me if it's wrong.

I meant it when I said I don't know which one of those 2 options in my previous mail is the right one, can you cast some light on it? Or, is this already solved in dotty, then how?

On Sat, May 4, 2013 at 5:19 PM, Paul Phillips <pa...@improving.org> wrote:

Perhaps https://issues.scala-lang.org/browse/SI-7278 is what you're looking for.

--

[Jan Vanek]

I get it now. You pointed that one because it's just another unsoundness hole in one out of many varieties. Frustrating. But that is not what I expect from you ;-)

On Sat, May 4, 2013 at 5:19 PM, Paul Phillips <pa...@improving.org> wrote:

Perhaps https://issues.scala-lang.org/browse/SI-7278 is what you're looking for.

--