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

lub/glb for HKTs #6352

Merged
merged 1 commit into from
Aug 7, 2018
Merged

lub/glb for HKTs #6352

merged 1 commit into from
Aug 7, 2018

Conversation

joroKr21
Copy link
Member

@joroKr21 joroKr21 commented Feb 26, 2018

When computing the lub/glb of HKTs take care to produce
well-kinded types. Improves type inference.

A few tests with -Xstrict-inference were changed.
Other tests reveal a limitation of higher-kinded existentials.

Fixes scala/bug#8882 and promotes scala/bug#10700 to an error.

@scala-jenkins scala-jenkins added this to the 2.13.0-M4 milestone Feb 26, 2018
@@ -4713,19 +4713,22 @@ trait Types
NoType
}
else {
if (tparam.variance == variance) lub(as, depth.decr)
else if (tparam.variance == variance.flip) glb(as, depth.decr)
val hktParams = tparam.typeParams
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is reusing this gonna break anything?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also things like this are probably still broken: class Foo[F[G[_] <: F[G]]]

@@ -1,4 +1,4 @@
hk-bad-bounds.scala:4: error: type arguments [Set] do not conform to class SeqFactory's type parameter bounds [CC[X] <: Seq[X] with scala.collection.generic.GenericTraversableTemplate[X,CC]]
hk-bad-bounds.scala:4: error: can't existentially abstract over parameterized type _1[X]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no memory of this place.

@@ -1,7 +1,7 @@
lub-from-hell-2.scala:3: error: type arguments [Any,Iterable[Any] with Int => Any with scala.collection.generic.Subtractable[Any,Iterable[Any] with Int => Any with scala.collection.generic.Subtractable[Any,Iterable[Any] with Int => Any]{def seq: Iterable[Any] with Int => Any}]{def seq: Iterable[Any] with Int => Any{def seq: Iterable[Any] with Int => Any}}] do not conform to trait Subtractable's type parameter bounds [A,+Repr <: scala.collection.generic.Subtractable[A,Repr]]
def foo(a: Boolean, b: collection.mutable.Set[Any], c: collection.mutable.ListBuffer[Any]) = if (a) b else c
^
lub-from-hell-2.scala:4: error: type arguments [Any,scala.collection.mutable.Iterable[Any] with scala.collection.mutable.Cloneable[scala.collection.mutable.Iterable[Any] with scala.collection.mutable.Cloneable[scala.collection.mutable.Iterable[Any] with Cloneable with Int => Any] with Int => Any{def seq: scala.collection.mutable.Iterable[Any] with Cloneable with Int => Any}] with scala.collection.generic.Growable[Any] with Int => Any with scala.collection.generic.Shrinkable[Any] with scala.collection.generic.Subtractable[Any,Iterable[Any] with Int => Any with scala.collection.generic.Subtractable[Any,Iterable[Any] with Int => Any]{def seq: Iterable[Any] with Int => Any}] with scala.collection.script.Scriptable[Any]] do not conform to trait Subtractable's type parameter bounds [A,+Repr <: scala.collection.generic.Subtractable[A,Repr]]
lub-from-hell-2.scala:4: error: type arguments [Any,scala.collection.mutable.Iterable[Any] with scala.collection.mutable.Cloneable[scala.collection.mutable.Iterable[Any] with scala.collection.mutable.Cloneable[scala.collection.mutable.Iterable[Any] with Cloneable with Int => Any] with Int => Any{def seq: scala.collection.mutable.Iterable[Any] with Cloneable with Int => Any}] with scala.collection.generic.Growable[Any] with Int => Any with scala.collection.generic.Shrinkable[Any] with scala.collection.generic.Subtractable[Any,Iterable[Any] with Int => Any with scala.collection.generic.Subtractable[Any,Iterable[Any] with Int => Any]{def seq: Iterable[Any] with Int => Any}] with scala.collection.script.Scriptable[Any]{def clone(): scala.collection.mutable.Iterable[Any] with scala.collection.mutable.Cloneable[scala.collection.mutable.Iterable[Any] with Cloneable with Int => Any] with scala.collection.generic.Growable[Any] with Int => Any with scala.collection.generic.Shrinkable[Any] with scala.collection.generic.Subtractable[Any,Iterable[Any] with Int => Any] with scala.collection.script.Scriptable[Any]{def clone(): scala.collection.mutable.Iterable[Any] with Cloneable with scala.collection.generic.Growable[Any] with Int => Any with scala.collection.generic.Shrinkable[Any] with scala.collection.script.Scriptable[Any]; def seq: scala.collection.mutable.Iterable[Any] with Cloneable with Int => Any}; def seq: scala.collection.mutable.Iterable[Any] with scala.collection.mutable.Cloneable[scala.collection.mutable.Iterable[Any] with Cloneable with Int => Any] with Int => Any{def seq: scala.collection.mutable.Iterable[Any] with Cloneable with Int => Any}; def companion: scala.collection.generic.GenericCompanion[[X]scala.collection.mutable.Iterable[X] with Cloneable with scala.collection.generic.Growable[X] with scala.collection.generic.Shrinkable[X] with scala.collection.script.Scriptable[X]]}] do not conform to trait Subtractable's type parameter bounds [A,+Repr <: scala.collection.generic.Subtractable[A,Repr]]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there is any use case for refining all of those members.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about not doing the refinements for F-bounded types, assuming there is any way to detect that?

@joroKr21 joroKr21 force-pushed the hkt-lub branch 5 times, most recently from 7e0f8e1 to fe98bfa Compare February 28, 2018 08:43
@joroKr21

This comment has been minimized.

@joroKr21 joroKr21 changed the title [WIP] lub/glb for HKTs lub/glb for HKTs Mar 14, 2018
@joroKr21 joroKr21 force-pushed the hkt-lub branch 3 times, most recently from 21399c8 to 9a68913 Compare April 25, 2018 06:18
@joroKr21

This comment has been minimized.

Copy link
Contributor

@adriaanm adriaanm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Small nits submitted as a git push.

When computing the `lub/glb` of HKTs take care to produce
well-kinded types when merging type constructor arguments
that are supplied for a type constructor parameter.

This improves type inference.

A few tests with `-Xstrict-inference` were changed.
Other tests reveal a limitation of higher-kinded existentials.

Fixes scala/bug#8882 and promotes scala/bug#10700 to an error.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants