regression 2.8 Existential type error: "kinds of the type arguments (?) do not conform to the expected kinds of the type parameters (type A) in trait T.

[scabug]

~$$ scala-2.8.0 
Welcome to Scala version 2.8.0.r18583-b20090827020153 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_13).
Type in expressions to have them evaluated.
Type :help for more information.

scala> trait T[A[_]]; type T1 = T[A] forSome { type A[_] }

<console>:4: error: kinds of the type arguments (?) do not conform to the expected kinds of the type parameters (type A) in trait T.
?'s type parameters do not match type A's expected parameters: <none> has no type parameters, but type A has one
       trait T[A[_]]; type T1 = T[A] forSome { type A[_] }
                                     ^

works in 2.7.5

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-2308?orig=1
Reporter: @retronym

[scabug]

@retronym said:
This is another manifestation of the problem:

existential.scala:

trait Request[IN[_]]
trait T[A]
val request: Request[IN] forSome { type IN[_] } = new Request[T] {}

~$$ scala-2.7.5 ~/Desktop/existential.scala 
~$$ scala-2.8.0 ~/Desktop/existential.scala 
(fragment of existential.scala):3: error: type mismatch;
 found   : java.lang.Object with this.Request[this.T]{ ... }
 required: this.Request[_[_]]
var request: Request[IN] forSome { type IN[_] } = new Request[T] {}
                                                   ^
one error found
!!!
discarding <script preamble>
~$$ scala-2.8.0 -version
Scala code runner version 2.8.0.r18583-b20090827020153 -- Copyright 2002-2009, LAMP/EPFL

[scabug]

@paulp said:
Hey adriaan - I have been working on a new toy, it still needs some polish before general usage but I went searching for regressions to test it out.

% whatbroke 2308
[...]
commit 7d041c9c19a1917ddaaeda894e8fade3c43636b3
Author: moors <moors@5e8d7ff9-d8ef-0310-90f0-a4852d11357a>
Date:   Thu Aug 13 08:37:19 2009 +0000

    fix for 513: use deep ForeachTypeTraverser in doTypeTraversal instead of shallow one
    test case+checkfile for SI-513
    
    git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@18473 5e8d7ff9-d8ef-0310-90f0-a4852d11357a

So in case you didn't already know, r18473.

[scabug]

@adriaanm said:
Replying to [comment:5 extempore]:

Hey adriaan - I have been working on a new toy, it still needs some polish before general usage but I went searching for regressions to test it out.
{code}
% whatbroke 2308
Awesome! Git bissect and scalatest, together at last?

[...]
commit 7d041c9c19a1917ddaaeda894e8fade3c43636b3
Author: moors moors@5e8d7ff9-d8ef-0310-90f0-a4852d11357a
Date: Thu Aug 13 08:37:19 2009 +0000

fix for 513: use deep ForeachTypeTraverser in doTypeTraversal instead of shallow one
test case+checkfile for #513

git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@18473 5e8d7ff9-d8ef-0310-90f0-a4852d11357a

}}
So in case you didn't already know, r18473.
I didn't, actually, so that's good to know. However, I don't think this caused the bug, it simply lifted the rock under which it was hiding. It's got something to do with scoping and symbols being entered with the right type params, but then all of a sudden the next lookup of that symbol doesn't see the type params yet. I've been trying to debug it, but haven't found a good strategy yet...

[scabug]

@retronym said:
I've been digging into this a little deeper.

For the first problem:

trait T[A[_]];
object Bug2308A {
  type T1 = T[B] forSome { type B[_] }
}

A naive trip through the debugger suggests that:

1. RefChecks.transformStat:928 substitutes the existential parameter B[_] with WildcardType.
2. Infer.checkKindBoundsHK compares the type argument WildcardType with the type parameter A[_], and reports the arity mismatch.

Perhaps RefChecks.transformStat could be modified to replaced existential types with a wildcard with the same structure (e.g. B[_] => new WildCardParameterisedType(WildCardType); or checkKindBoundsHK could add a special case to short circuit the check.

---

The second problem, which is blocking the port of part of Scalaz, is eluding me. It is minimally:

trait Request[IN[_]]
trait T[A]
(null: Request[T]) : (Request[IN] forSome { type IN[_] })

Which part of the type conformance checking should return true for T <:< IN[_] ? Types.isHKSubType0 does not, as (tp1.normalize, tp2.normalize) results in a pair of type (TypeVar, PolyType), which falls through to the default case. But I could be looking in entirely the wrong place...

[scabug]

@adriaanm said:
I overlooked that this involves higher-kinded existentials -- it's non-trivial to support those. See also #1369.

[scabug]

@adriaanm said:
other dups: #975, #1227
higher-kinded existentials were introduced in r12113

[scabug]

@retronym said:
Another usecase for this is accessing the class of a type that has a higher kinded type parameter:

scala> trait T[M[_]]
defined trait T

scala> classOf[T[X] forSome{ type X[_] }]
<console>:5: error: kinds of the type arguments (?) do not conform to the expect
ed kinds of the type parameters (type M) in trait T.
?'s type parameters do not match type M's expected parameters: <none> has no typ
e parameters, but type M has one

[scabug]

Commit Message Bot (anonymous) said:
(extempore in r25114) When TypeVars were given higher-order abilities, so too should
have been WildcardType, which acts as a plceholder for typevars.
Always inflicting arguments upon it was the cause of #2308.
Closes #2308, review by moors.