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 new ... ellipsis keyword #7440

Open
Tracked by #7106
smores56 opened this issue Dec 30, 2024 · 2 comments
Open
Tracked by #7106

Add new ... ellipsis keyword #7440

smores56 opened this issue Dec 30, 2024 · 2 comments
Labels
can Relates to the Canonicalization compiler stage intermediate issue Likely good for someone who has completed a few other issues parsing Relates to the Parsing compiler stage type checking Relates to type checking compiler stage

Comments

@smores56
Copy link
Collaborator

To support incomplete code, we want to add a new ... ellipsis keyword (not an operator, since it doesn't operate on anything, even though it's not a word). It will be a syntax node that takes no arguments and acts somewhat like crash "Not yet written". The difference being that:

  • An ellipsis won't trigger "unreachable code" errors
  • It is considered as a new type of code issue: a note, in addition to errors and warnings.
    • For reporting notes, they should be highlighted as issues in code (but not doc code blocks), but only reported if there are no errors or warnings.
    • Notes should return a non-zero exit code to imply that there is an issue.
    • Notes should also be aggregated at the module level, something like:
── UNFINISHED CODE in path/To/Module.roc ───────────────────────────────────────

I still see a 3 places where code was left unfinished in this module:

35| if x == ... then
            ^^^

37| abc = ...
          ^^^

60| func.call("foo", ...)
                     ^^^

────────────────────────────────────────────────────────────────────────────────

0 errors and 0 warnings found in XYZ ms.

A good way to implement this would probably be to desugar this to crash "Not yet written", but add a kind: CrashKind field on roc_can crash nodes to report compilation issues differently for ellipses and normal crashes.

@smores56 smores56 added parsing Relates to the Parsing compiler stage type checking Relates to type checking compiler stage can Relates to the Canonicalization compiler stage intermediate issue Likely good for someone who has completed a few other issues labels Jan 1, 2025
@lishaduck
Copy link

For clarity for whoever implements this (as there isn't a linked a Zulip thread), this wouldn't be for type annotations, where the existing type hole (_) type would be used instead, right?

@smores56
Copy link
Collaborator Author

smores56 commented Jan 2, 2025

That's correct! This is just for arbitrary expressions in code and in doc code blocks.

@smores56 smores56 mentioned this issue Jan 3, 2025
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
can Relates to the Canonicalization compiler stage intermediate issue Likely good for someone who has completed a few other issues parsing Relates to the Parsing compiler stage type checking Relates to type checking compiler stage
Projects
None yet
Development

No branches or pull requests

2 participants