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

Integrate higher-rank polymorphism on block parameters #298

Merged
merged 6 commits into from
Nov 7, 2023

Conversation

dvdvgt
Copy link
Collaborator

@dvdvgt dvdvgt commented Oct 30, 2023

This PR resolves #246 and integrates higher-rank polymorphism on block parameters. This only required a few changes:

  • The Parser had to be changed slightly to optionally accept type parameters for block types and type arguments for function arguments.
  • The pretty printer for types was changed such that value parameters are in parentheses if type parameters are present, e.g., [A]List[A] => Int is instead pretty printed as [A](List[A]) => Int.
  • The namer required a slight change but for here onward, no changes seem to be required.

@b-studios
Copy link
Collaborator

Approved by the Effekt committee in person :)

@b-studios b-studios merged commit e8136ac into master Nov 7, 2023
2 checks passed
@b-studios b-studios deleted the feature/higher-rank-poly branch November 7, 2023 16:47
@@ -228,7 +228,9 @@ class EffektParsers(positions: Positions) extends EffektLexers(positions) {
)

lazy val functionArg: P[BlockLiteral] =
( `{` ~> lambdaParams ~ (`=>` ~/> stmts <~ `}`) ^^ { case (vps, bps) ~ body => BlockLiteral(Nil, vps, bps, body) : BlockLiteral }
( `{` ~> (`[` ~> manySep(idDef, `,`) <~ `]`).? ~ lambdaParams ~ (`=>` ~/> stmts <~ `}`) ^^ {
Copy link
Collaborator

Choose a reason for hiding this comment

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

@dvdvgt maybe we can refactor this to add types to lambdaParams

Copy link
Collaborator

Choose a reason for hiding this comment

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

Or at the very least use existing maybeTypeParams :)

( (`(` ~> manySep(valueType, `,`) <~ `)`) ~ many(blockTypeParam) ~ (`=>` ~/> primValueType) ~ maybeEffects ^^ FunctionType.apply
| some(blockTypeParam) ~ (`=>` ~/> primValueType) ~ maybeEffects ^^ { case tpes ~ ret ~ eff => FunctionType(Nil, tpes, ret, eff) }
| primValueType ~ (`=>` ~/> primValueType) ~ maybeEffects ^^ { case t ~ ret ~ eff => FunctionType(List(t), Nil, ret, eff) }
( (`[` ~> manySep(idDef, `,`) <~ `]`).? ~ (`(` ~> manySep(valueType, `,`) <~ `)`).? ~ many(blockTypeParam) ~ (`=>` ~/> primValueType) ~ maybeEffects ^^ {
Copy link
Collaborator

Choose a reason for hiding this comment

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

@dvdvgt maybe have auxiliary definition for typeParam to make the role of Id explicit?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I just noticed, we already have maybeTypeParams for this.

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.

Higher-rank polymorphism
2 participants