Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Illegal type selection from volatile type null in return type projection #6042

Closed
scabug opened this issue Jul 7, 2012 · 12 comments
Closed

Comments

@scabug
Copy link

scabug commented Jul 7, 2012

The code below worked in 2.9.2 but not in 2.10.0-M4.
The return type projection Exp#OpSemExp#Val raises the obscure compile time error "Illegal type selection from volatile type null", so Exp#Val is not seen as a subtype of Exp#OpSemExp#Val anymore. For semantic reasons it is not allowed to remove #Val. It must work like that.

case class LamExpWaiter(xs: Seq[Idn]) { 
  def apply[Exp <: LazyExp[_]](e: Exp): Exp#OpSemExp#Val = 
    apply_helper(e.asInstanceOf[Exp#OpSemExp]) 
  def apply_helper[Exp <: LazyExp[Exp]](e: Exp): Exp#Val = 
    e.reify_lam(xs, e) 
} 

This issue seems to be a blocker, because the coder has to go to 2.10 for TypeTag, because there is another problem in which Manifest is too limited.
see thread http://groups.google.com/group/scala-user/browse_thread/thread/599b99bb2ee9ddd2

The associated thread of this issue is:
http://groups.google.com/group/scala-user/browse_thread/thread/ab77f705fe22a246

I have narrowed the code below. If I narrow it further then I get errors in 2.9.2 too, so this is the minimal representative (I assume, because I don't know if semantically that statement is true, I don't understand this kind of type level programming) and maybe can be used as unit test. However use the project EDSL as regression test, because there might be some other issue connected that can popup and then is useless for the original coder.

class BaseApp[+Exp <: LazyExp[_]](val e: Exp, val x: String) 

trait AbsVal[+Exp <: LazyExp[_]] 

trait LamReifierBase { 
  def reify_lam[Exp <: LazyExp[Exp]](xs: Seq[String], e: Exp): Exp#Val 
} 

trait LazyExp[+This <: LazyExp[This]] {
  type OpSemExp <: LazyExp[OpSemExp] with This 
  type Val <: AbsVal[This] with This 
  type App <: BaseApp[This] with This 

  protected val lr: LamReifierBase 
  def reify_lam[Thiz >: This](xs: Seq[String], e: Thiz): This#Val = 
    lr.reify_lam(xs, e.asInstanceOf[This]) 
}

case class LamExpWaiter(xs: Seq[String]) { 
  def apply[Exp <: LazyExp[_]](e: Exp): Exp#OpSemExp#Val = 
    apply_helper(e.asInstanceOf[Exp#OpSemExp]) 
  def apply_helper[Exp <: LazyExp[Exp]](e: Exp): Exp#Val = 
    e.reify_lam(xs, e) 
}  
@scabug
Copy link
Author

scabug commented Jul 7, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6042?orig=1
Reporter: DaveScala (davescala)
Affected Versions: 2.10.0-M4
See #3443
Attachments:

  • EDSL.zip (created on Jul 7, 2012 4:57:00 PM UTC, 3693 bytes)

@scabug
Copy link
Author

scabug commented Jul 7, 2012

DaveScala (davescala) said:
Eclipse 3.71 scala 2.10.0-M4 project

@scabug
Copy link
Author

scabug commented Jul 7, 2012

@paulp said:
I am sure it did not work in 2.9.2; it would issue many errors such as "not found: type Idn". Please submit compilable code when opening tickets.

@scabug
Copy link
Author

scabug commented Jul 7, 2012

DaveScala (davescala) said:
Have you tried it? Idn is in Package.scala

@scabug
Copy link
Author

scabug commented Jul 7, 2012

@paulp said:
I haven't downloaded the attachment, which I admit I didn't notice but doesn't actually alter anything. In almost every case, certainly in this one, if you need an attachment to report the bug, then you aren't finished minimizing it.

@scabug
Copy link
Author

scabug commented Jul 7, 2012

DaveScala (davescala) said:
I am only passing this on. But never mind, leave the bug where it is.

@scabug
Copy link
Author

scabug commented Jul 8, 2012

@retronym said:
The attached four file repro isn't minimal, but it will do.

I suspect that it's related to stricter/better as-seen-from in the light of existentials; I'll poke around a bit more and report back soon.

@scabug
Copy link
Author

scabug commented Jul 8, 2012

@harrah said:
Somewhat related is #3443. Relying on two consecutive type projections is probably risky.

@scabug
Copy link
Author

scabug commented Jul 8, 2012

@retronym said (edited on Jul 8, 2012 1:08:40 PM UTC):
I believe that the error is accurate. I've improved the error message a little:

scala/scala#850

It will now issue:

 t6042.scala:7: error: illegal type selection from volatile type a.OpSemExp (with upper bound LazyExp[a.OpSemExp] with _$1)

The with _$1 part is the reason we can't project the type Val. It corresponds to with This in type alias definition, substituted with a existential skolem.

@scabug
Copy link
Author

scabug commented Jul 8, 2012

DaveScala (davescala) said:
I indeed found that removing 'with This' in

type OpSemExp <: LazyExp[OpSemExp] with This

into

type OpSemExp <: LazyExp[OpSemExp]

did make the error go away and then projecting on Val is possible.
but it probably means something else.

But is the type selection volatile because of type erasure?
Then the workaround would be to put a typetag somewhere.

Only this

trait LazyExp[+This <: LazyExp[This]: TypeTag] 

is not allowed.

scala> trait LazyExp[+This <: LazyExp[This]: TypeTag]
<console>:1: error: traits cannot have type parameters with context bounds `: ..
.' nor view bounds `<% ...'
       trait LazyExp[+This <: LazyExp[This]: TypeTag]
                                                      ^

Probably the type parameter This is volatile because of type erasure.

Maybe macros?

@scabug
Copy link
Author

scabug commented Jul 8, 2012

@retronym said (edited on Jul 8, 2012 2:11:25 PM UTC):
The problem is existential types. Erasure / Type Tags / Manifest are unrelated to this completely -- they determine how type information is carried from compile time to runtime; this program doesn't compile at all so that's not relevant.

Dependent method types might offer a solution here. It would be best to move further discussion to the mailing list.

(Closed as "not a bug" because the type error is correct, the error message itself was buggy and has been fixed)

@scabug scabug closed this as completed Jul 8, 2012
@scabug
Copy link
Author

scabug commented Jul 8, 2012

DaveScala (davescala) said:
Okay thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants