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

Make annotations richer #178

Open
4 of 8 tasks
dahlia opened this issue Aug 26, 2017 · 2 comments
Open
4 of 8 tasks

Make annotations richer #178

dahlia opened this issue Aug 26, 2017 · 2 comments
Assignees
Labels
cat:lang Category: Language design cmp:compiler Component: Compiler backend (e.g., annotation processors, code generators) typ:enhance Type: Enhancement/new feature
Milestone

Comments

@dahlia
Copy link
Member

dahlia commented Aug 26, 2017

The current syntax of annotations is very limited:

  • They can has only zero or one parameter.
  • Their argument cannot be other than a string.

In order to make it usable for production (e.g. #130), make annotations richer through addition of the following features:

@dahlia dahlia added typ:enhance Type: Enhancement/new feature cat:lang Category: Language design cmp:compiler Component: Compiler backend (e.g., annotation processors, code generators) labels Aug 26, 2017
@dahlia
Copy link
Member Author

dahlia commented Aug 27, 2017

In order to disambiguate annotations when multiple consumers (i.e. targets, runtimes) interpret them, we can make them exclusively allowed to have multiple keyword arguments or a single argument, not both e.g.:

@nullary-annotation  // allowed 🙆🏻
type a = foo;

@unary-annotation("arg")  // allowed 🙆🏻
type b = foo;

@single-keyword-annotation(x = "arg")  // allowed 🙆🏻; keyword syntax is arbitrary for example
type c = foo;

@multiple-keywords-annotation(x = "arg1", y = "arg2")  // allowed 🙆🏻
type d = foo;

@n-ary-annotation("arg1", "arg2")  // disallowed 🙅🏻‍♂️
type e = foo;

@dahlia
Copy link
Member Author

dahlia commented Aug 27, 2017

we can make them exclusively allowed to have multiple keyword arguments or a single argument, not both

Or rather simply we can make them allowed to have only keywords, not positional arguments. Of course this approach need to break backward compatibility, which is less important for now.

@dahlia dahlia added this to the Version 0.4.0 milestone Feb 18, 2018
@dahlia dahlia modified the milestones: Version 0.4.0, Version 0.5.0 May 5, 2018
@kanghyojun kanghyojun self-assigned this May 11, 2018
@kanghyojun kanghyojun moved this from Chosen to In progress in Sprint at Seoul in May 2018 May 11, 2018
@kanghyojun kanghyojun moved this from In progress to In review in Sprint at Seoul in May 2018 May 12, 2018
@kanghyojun kanghyojun moved this from In review to Delivered in Sprint at Seoul in May 2018 May 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cat:lang Category: Language design cmp:compiler Component: Compiler backend (e.g., annotation processors, code generators) typ:enhance Type: Enhancement/new feature
Projects
No open projects
Development

No branches or pull requests

2 participants