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

DSL generics #24

Closed
MeAmAnUsername opened this issue Jun 28, 2020 · 7 comments
Closed

DSL generics #24

MeAmAnUsername opened this issue Jun 28, 2020 · 7 comments
Labels
Component: DSL Something that concerns the design of PIE DSL Priority: medium Status: blocked Status: done Type: enhancement New feature or request

Comments

@MeAmAnUsername
Copy link
Owner

MeAmAnUsername commented Jun 28, 2020

Generics for PIE DSL
Full generics cannot be implemented in NaBL2, but some parts can.
This proposal aims to implement generics for data types.

use cases

  • foreign functions may return generics, e.g. JSGLR1ParseResult.getAst() returns an Optional<T>
    • in particular, spoofax 3 tasks return Result<T, E>
  • Create generic functions, e.g. assertEquals(expected: T, actual: T, message: string) -> unit

syntax

New type: Type.GenericTy = [[ID]<{[ID] ", "}+>]. Exactly the same as Java, e.g. Result<T, E>. Can be used everywhere a type is used.

Functions gain the ability to specify generic type parameters:
func createOk<T: Object>(val: T) -> Result<T, Exception> = foreign java mb.common.result.Result#ofOk
func id<T>(val: T) -> T = val

Call a generic function:
val result = createOk<Foo*>([createFoo()]);
Requirement to explicitly add types may be lifted in the future (presumably requires statix analysis though).

Static semantics

For now, data Foo<Bar>: Bar must be a valid data type, it is not a generic data type.
Later: allow data Foo<T: Language>. If the generic type parameter adds a supertype it is a generic parameter, without a parameter it is specific. Allow T: _ to use TopTy as parameter.
Even later: deprecate data Foo<T>. After deprecation, data Foo<T> becomes syntactic sugar for Foo<T: _>
func createOk<T: Object>(...)

Code generation:

[todo]

Issues

[todo]

@MeAmAnUsername MeAmAnUsername added Type: enhancement New feature or request Status: proposal Enhancement in the proposal stage Component: DSL Something that concerns the design of PIE DSL Priority: medium labels Jun 28, 2020
@MeAmAnUsername MeAmAnUsername added Status: in progress and removed Status: proposal Enhancement in the proposal stage labels Oct 15, 2020
@MeAmAnUsername
Copy link
Owner Author

Trying this today to see if it works; otherwise this will be deemed impossible until static semantics are implemented in Statix

@MeAmAnUsername
Copy link
Owner Author

Status update: implementing static semantics in Statix since end of November. Currently still translating existing semantics, but it seems likely that generics can easily be implemented with Statix.

@MeAmAnUsername
Copy link
Owner Author

Clarification on previous comment: I expect that generics will be hard, but mostly due to the inherent complexity of generics, not due to the incidental complexity of Statix

@MeAmAnUsername
Copy link
Owner Author

Blocked by ambiguity in #208

@MeAmAnUsername
Copy link
Owner Author

There is an implementation to resolve #208 (syntax was changed from Foo<T> to Foo[T]) so this issue is now unblocked again.

Still to do: add a few compiler tests so that there is some protection against regressions.

@MeAmAnUsername
Copy link
Owner Author

Blocked again by syntax issues, this time by #237.

@MeAmAnUsername
Copy link
Owner Author

Implemented, currently opening PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: DSL Something that concerns the design of PIE DSL Priority: medium Status: blocked Status: done Type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant