Skip to content

Change/higher kinded #137

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

Merged
merged 23 commits into from
Jul 9, 2014
Merged

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 20, 2014

This is the new higher-kinded scheme.

odersky added 19 commits June 12, 2014 12:55
… abstract type.

This is needed to make the encoding og higher-kinded types work. E.g.

    Rep[Int]

would be represented as

    Rep { type Arg$0 = Int } # Apply

where Apply is an abstract member of the base class Lambfa$I of Rep.
Adding names and definitions for the Lambda scheme to hk types.
Also add HigherKinded flag for HK type parameters and abstract types.
Testing whether a type is (a subtype of) a Lambda class.
... to bring it in sync with equals.
Type members used to always pick the last refined info for a type name.
This is incorrect, as a type might have several refinements for the
same type name, which are not necessarily subsumed by the last one.
We now only pick the last one if it is an alias type (assuming we check
for conflicts elsewhere).
Make sure that Lambda Arg refinements have the same variance as the Lambda classes
they instantiate. Controlled by a Config parameter.
Apply cannot be treated as a type parameter because it does not count
towards the number of legal arguments in an instantiation of a higher-kinded
type.
Now also works for symbols that are not class members (and returns
Iterator.empty for them).
Avoid to reduce projections `A{ ... }#T` to aliases if the
alias would refer to abstract members of the refinement type.
Printing a type parameter reference `A#T` now only reduces to `T` if
`A` is some `B.this.type`.
In case of "types differ" failure, explain why original and retyped type are
not subtypes of each other.
Refined type subtyping needs to take into account all information
that was seen about members of both refined types. This is handled by
storing context info in `pendingRefinedBases` and making use of this
to selective rebase qualifiers when comparing refined types.

Note: This commit fails in pos/collections and dotc/ast, presumably because
of bad interaction between the refined subtyping and the "matchingNames" logic
(which will go away).
Switch to the new scheme where higher-kinded types (and also some polymorphic
type aliases) are represented as instances of Lambda traits.
1) Honor variance of Apply and $hkArgs when instantiating them
2) Eta-lifting a higher-kinded type is straight eta expansion,
   no arguments are applied.
Was not called when comparing a named type with an #Apply projection. The commit fixes this.
refines needs to be made more stable, so that also aliases and derefernces typevars are recognized as prefixes.
TypeVars flip from the initial state, where underlying == origin to the final state
where underlying == inst. This flip can invalidate information that depends on the underlying
type of a TypeVar. Since we do not know when the flip occurs, we need to avoid keeping
any such information in a cache.

The commit makes three caches depend on a new value: typerState.ephemeral. The value is
set to `true` each time we follow the underlying type of a TypeVar, and this disables cached
information to be retained.

A test case for this commit is t2693.scala. This test passes typechecking with the previous commit,
but fails in -Ycheck:front because of stale cache info in an "#Apply" typeref. The present commit fixes that.
@odersky
Copy link
Contributor Author

odersky commented Jun 20, 2014

Reviews by @DarkDimius @adriaanm


/** The HigherKinded trait corresponding to symbols `boundSyms` (which are assumed
* to be the type parameters of a higher-kided type). This is a class symbol that
* would be generated by the following schema.
*
* class HigherKindedXYZ { type v_n _$hk$0; ...; type v_n _$Hk$n }
* class LambdaXYZ { type v_1 Arg1; ...; type v_N ArgN; type Apply }
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the parentTraitRefs from the implementation should be described in this comment, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

right. I'll add an explanation.

else pre.refinedInfo match {
case TypeBounds(lo, hi) /*if lo eq hi*/ => hi
case TypeBounds(lo, hi) if lo eq hi =>
if (hi.existsPart(dependsOnThis)) NoType else hi
Copy link
Contributor

Choose a reason for hiding this comment

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

does existsPart look at bounds?

consider class C { type X } ; P { self => type T = C { type X <: self.U }; type U } # T

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it follows bounds in a refinement.

@adriaanm
Copy link
Contributor

I had to resort to skimming due to the size. I'm also new to the codebase, so I hope my comments make (some) sense.

Guard every occurrence of name.head with a test whether name.length > 0
@odersky
Copy link
Contributor Author

odersky commented Jun 26, 2014

Thanks for the very helpful comments, Adriaan! I add two more commits to address them.

odersky added 3 commits June 26, 2014 13:17
Avoid special treating TermRef, as this is not demanded by the
comment and does not change any of the test outcomes.
Added explanations where suggested by Adriaan in his review.
DarkDimius added a commit that referenced this pull request Jul 9, 2014
@DarkDimius DarkDimius merged commit 1c4e9c2 into scala:master Jul 9, 2014
@allanrenucci allanrenucci deleted the change/higher-kinded branch December 14, 2017 16:58
WojciechMazur pushed a commit to WojciechMazur/dotty that referenced this pull request Mar 19, 2025
Backport "Rethrow SuspendExceptions caught in CodeGen phase" to 3.3 LTS
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