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

Add keyword parameters to function type signatures #2077

Open
jurgenvinju opened this issue Nov 13, 2024 · 0 comments
Open

Add keyword parameters to function type signatures #2077

jurgenvinju opened this issue Nov 13, 2024 · 0 comments
Assignees

Comments

@jurgenvinju
Copy link
Member

Is your feature request related to a problem? Please describe.

Because we can't declare the names and types in function types, only on the type signatures of function definitions, the code that uses first class functions does not have access to the keyword parameters feature at all.

  • The interpreter works anyway because it only warns about additional parameters being provided without stopping execution.
  • The type checker must provide a critical error since without a declaration no type checking can be done.
  • This is mostly a grammatical omission. We simply can't type int (int param=...)
  • Function types can't and shouldn't have default expressions. That is strictly a feature of function and constructor definitions. Otherwise we'd introduce a multiple inheritance situation. By sticking defaults to concrete function definitions each first-class function definition will always have one unique default expression per keyword parameter.

Describe the solution you'd like

  • Stick as closely as possibly to the syntax of function definitions.
  • Only put a placeholder like ... or default next to the = sign of the keyword field.
  • Reuse existing internal types for function in AType and Symbol that already fully support keyword parameters.

Describe alternatives you've considered

  • Turning the error into a warning; but that can introduce java compilation errors, cast exceptions and NPE's in code generated for "correct" rascal programs

Additional context

  • This is very relevant for typepal and the rascal typechecking which both use first class functions a lot as members of data constructors.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants