[scala] is this a bug?

[Meredith Gregory]

All,

Here is a little codesnippet. Everything is fine up to the last decl. That generates the following compiler error.

error: type arguments [MSequitor,A] do not conform to trait MBraceSeq's type parameter bounds [C[_] <: MBrace[C,A] with Seq[A],A]
       class MBraceSequitor[A] extends MBraceSeq[MSequitor,A] {

i haven't been able to convince myself that the type checker is correct. Can someone else take a look and see if the checker's complaint is reasonable or if i should file a ticket?

Best wishes,

--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Jesper Nordenberg]

Meredith Gregory wrote:
> All,
>
> Here is a little codesnippet <http://paste.pocoo.org/show/125132/>.
> Everything is fine up to the last decl. That generates the following
> compiler error.

Can't say I fully understand higher kinded types. A little example
influenced by your code:

trait T[A[_] <: T[A, B], B]
trait T2[B] extends T[T2, B]

This is valid Scala code, but what does it mean? I can see two
possibilities:

- There exists a C for which "T2[C] <: T[T2, B]" holds, which obviously
is true if C = B. But how is this even useful?

- For all C "T2[C] <: T[T2, B]" must hold, which clearly is not true and
would indicate a compiler bug.

/Jesper Nordenberg

[nuttycom]

On Thu, Jun 25, 2009 at 3:17 PM, Jesper Nordenberg<megagurka@...> wrote:

> Meredith Gregory wrote:
>>
>> All,
>>
>> Here is a little codesnippet <http://paste.pocoo.org/show/125132/>.
>> Everything is fine up to the last decl. That generates the following
>> compiler error.
>
> Can't say I fully understand higher kinded types. A little example
> influenced by your code:
>
> trait T[A[_] <: T[A, B], B]
> trait T2[B] extends T[T2, B]
>
> This is valid Scala code, but what does it mean? I can see two
> possibilities:
>
> - There exists a C for which "T2[C] <: T[T2, B]" holds, which obviously is
> true if C = B. But how is this even useful?

That's essentially my take too - that having the parameterized type of
A be unconstrained is essentially useless except in the case where C =
B.

So why not define it as:

trait T[B, A[B] <: T[B, A]]

In this case, the dependency between the container type and the
contained type is strictly constrained. I'm not sure if this
restriction is overly narrow for his purposes, but at least within an
instance of the trait you can safely refer to the type of the
implementing class A[B]. An example of how this might play out in his
code is http://paste.pocoo.org/show/125150/

What am I missing here?

Kris

> - For all C "T2[C] <: T[T2, B]" must hold, which clearly is not true and
> would indicate a compiler bug.
>
> /Jesper Nordenberg
>
>

[Jesper Nordenberg]

Jesper Nordenberg wrote:
> - For all C "T2[C] <: T[T2, B]" must hold, which clearly is not true and
> would indicate a compiler bug.

Here's an even more contrived example:

trait T[A[Int] <: T[A, B], B]
class T2[B] extends T[T2, B]
new T2[Float]

This basically says that "T2[Int] <: T[T2, Float]" which obviously isn't
true, so there's seems to be some checks missing in the compiler.

/Jesper Nordenberg

[Adriaan Moors-2]

Hint:

trait T[A[Int] <: T[A, B], B]

is equivalent to

trait T[A[X] <: T[A, B], B]

it's like writing

def foo[Int](x: Int): Int,

which in turn is equivalent to

def foo[T](x: T): T

when you write an identifier in a position where a type parameter is expected, you introduce a new variable (thus, the "Int" in the above snippets does not refer to the existing type Int, but is just some type parameter with an unfortunate name)

hth

adriaan

On Fri, Jun 26, 2009 at 9:06 AM, Jesper Nordenberg <megagurka@...> wrote:

Jesper Nordenberg wrote:

- For all C "T2[C] <: T[T2, B]" must hold, which clearly is not true and would indicate a compiler bug.

Here's an even more contrived example:

trait T[A[Int] <: T[A, B], B]
class T2[B] extends T[T2, B]
new T2[Float]

This basically says that "T2[Int] <: T[T2, Float]" which obviously isn't true, so there's seems to be some checks missing in the compiler.

/Jesper Nordenberg


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[Jesper Nordenberg]

Adriaan Moors wrote:
> when you write an identifier in a position where a type parameter is
> expected, you introduce a new variable (thus, the "Int" in the above
> snippets does not refer to the existing type Int, but is just some type
> parameter with an unfortunate name)

Yes, I was suffering from a temporary brain-melt when posting that.
Still there's something fishy about my original example, here's a slight
variation:

trait T[A[C] <: T[A, B], B] {
   def x : T[A, B] = y
   def y : A[Int]
}

This indicates to me that the compiler considers that "A[C] <: T[A, B]"
holds for all C. The problem is that now we can define a subtype like this:

class T2[B] extends T[T2, B] { def y = new T2[Int] }

Here's an example how this causes problems:

scala> val t = new T2[Float]
t: T2[Float] = T2@d01311

scala> val t2 = t.x
<console>:7: error: type arguments [T2,Float] do not conform to trait
T's type parameter bounds [A[C] <: T[A,B],B]
        val t2 = t.x
            ^

Clearly something isn't right here.

/Jesper Nordenberg