Skip to content

Harmonize PolyType and TypeLambda #1560

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 10 commits into from
Oct 12, 2016

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Oct 6, 2016

Push as much as we can into common superclass GenericType. Review by @smarter.

Update: I managed to completely eliminate any distinction between PolyType and TypeLambda. They are the same type now, and GenericType as a supertype could also be eliminated.

@smarter
Copy link
Member

smarter commented Oct 6, 2016

Needs to be rebased after the inline merge

@odersky odersky force-pushed the change-one-polytype branch from 777c309 to 0653344 Compare October 6, 2016 14:57
@odersky
Copy link
Contributor Author

odersky commented Oct 6, 2016

Rebased to master

@odersky
Copy link
Contributor Author

odersky commented Oct 10, 2016

In theory this commit paves the way to allow polymorphic types as value types. A test of some
of the basic functionality is in pending/pos/polyTypes. This does not work yet, because adapt forces every polytype it sees to be fully applied. Enabling this functionality should be a SIP and separate PR.

@odersky odersky force-pushed the change-one-polytype branch from 6b0e68f to d1cd209 Compare October 10, 2016 11:48
@smarter smarter force-pushed the change-one-polytype branch from 2ab3e5c to bc786d7 Compare October 11, 2016 21:16
Let them inherit the same traits and push as much
functionality as possibly into the common superclass
GenericType.
to account for the fact the GenericTypes are now TypeProxies.
Otherwise we can run into problems when checking imports for e.g.
scala2Mode in later runs.
The refactored logic only applies to infos of denotations, not
general types. The reactoring avoids special cases down the road
then PolyTypes and MethodTypes can be used for terms as well as
type(bounds).
If PolyTypes are to become value types we want to keep `=>` as the arrow
for consistency. `->` should be reserved for PolyTypes that do not have
side effects on instantiation.
@smarter smarter force-pushed the change-one-polytype branch from bc786d7 to 9e74d72 Compare October 12, 2016 14:14
@smarter
Copy link
Member

smarter commented Oct 12, 2016

Rebased after the union-type PR merge

@smarter
Copy link
Member

smarter commented Oct 12, 2016

LGTM, I wonder if we can merge LambdaParam and PolyParam ?

@smarter smarter merged commit 1c62d05 into scala:master Oct 12, 2016
@odersky
Copy link
Contributor Author

odersky commented Oct 13, 2016

LGTM, I wonder if we can merge LambdaParam and PolyParam ?

Yes, interesting question. PolyParam is a reference to a parameter, whereas LambdaParam is a surrogate for a symbol, i.e. a definition. So it's not obvious, but still worth thinking about it.

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

Successfully merging this pull request may close these issues.

6 participants