Skip to content

Fix #1543: Add synthetic FunctionN types. #1553

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

Closed
wants to merge 1 commit into from

Conversation

nicolasstucki
Copy link
Contributor

With this change it is possible to have create types for
functions of any arity. This ensures that the compiler will
not crash when creating FunProto when typing a method
application method applications with more than MaxFunctionArity
parameters. Note that in the language the functions are still
bound to MaxFunctionArity, but this is a first small step towards
supporting any function arity.

@@ -753,7 +785,7 @@ class Definitions {
// ----- Initialization ---------------------------------------------------

/** Lists core classes that don't have underlying bytecode, but are synthesized on-the-fly in every reflection universe */
lazy val syntheticCoreClasses = List(
private lazy val syntheticCoreClasses = mutable.Set[Symbol](
Copy link
Contributor

@DarkDimius DarkDimius Oct 3, 2016

Choose a reason for hiding this comment

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

The order here matters, it should remain a List.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now it respects order again.

With this change it is possible to have create types for
functions of any arity. This ensures that the compiler will
not crash when creating FunProto when typing a method
application method applications with more than MaxFunctionArity
parameters. Note that in the language the functions are still
bound to MaxFunctionArity, but this is a first small step towards
supporting any function arity.
@OlivierBlanvillain
Copy link
Contributor

OlivierBlanvillain commented Oct 10, 2016

How much work do you think would be required to remove the dependency on FunctionN classes for method application?

@nicolasstucki
Copy link
Contributor Author

I'm not sure. I will try it again because it would be best to have a simple solution for this issue.

@nicolasstucki
Copy link
Contributor Author

I managed to find a trivial fix for this issue at the source of the problem. PR #1577 has this fix. This PR will become closed if the other one is merged.

@nicolasstucki
Copy link
Contributor Author

#1577 fixed issue #1543.

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.

4 participants