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

Backticky symbol parsing #3525

Merged
merged 50 commits into from Feb 26, 2024
Merged

Backticky symbol parsing #3525

merged 50 commits into from Feb 26, 2024

Conversation

mitchellwrosen
Copy link
Member

@mitchellwrosen mitchellwrosen commented Oct 19, 2022

Overview

This PR adds two features:

  1. Names now consist of 1+ wordy or symboly name segments. Previously, they consisted of 0+ wordy name segments followed by 1 wordy or symboly name segment. That means foo.++.doc is now valid, the primary purpose of the PR.

  2. Historical naming accidents . and () are now handled better - they are valid name segments, so long as they belong to a name segment escaped in backticks, e.g. `.` or `()()()`. Reserved symbols and names (such as = and match) are also valid name segments, if they are escaped (`=`, `match`).


Fixes #1519
Fixes #1589
Fixes #2970

(.) f g x = f (g x)
(`.`) f g x = f (g x)
Copy link
Contributor

Choose a reason for hiding this comment

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

This is interesting; it makes me think that there are some unambiguous syntaxes we could accept without ``, e.g. if it's in parens, all symbols, with no spaces, like the (.) above, or a group of symboly chars that are separated with spaces or other tokens, from any other identifiers, thus not a path-qualified name, like the id . id below, but this is still fine/good for now.

(base.function..) f g x = f (g x)
(base.function.`.`) f g x = f (g x)
Copy link
Contributor

Choose a reason for hiding this comment

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

Even with the relaxed rules proposed in the previous comment, this would still need the ``s, because it's got other . in it, which would mean it's a path-qualified name.

Comment on lines +892 to +895
-- yes "wordy" - just like a wordy keyword like "true", the literal "." (as in the dot in
-- "forall a. a -> a") is considered the keyword "." so long as it is either followed by EOF, a space, or some
-- non-wordy character (because ".foo" is a single identifier lexeme)
wordyKw "."
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not symboly, because the "eof/space/non-wordy-character" definition of wordy just is what we need here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, the definition of wordyKw is what we need here. I can't remember exactly what bug symbolyKw was causing at the moment, unfortunately, but it's not correct

@mitchellwrosen mitchellwrosen marked this pull request as ready for review February 22, 2024 20:32
@aryairani
Copy link
Contributor

@mitchellwrosen Could you add a regression test for #2970 and #1519 and then we'll get it merged.

@aryairani aryairani merged commit 0fdb7db into trunk Feb 26, 2024
7 checks passed
@aryairani aryairani deleted the 22-10-18-backticky-parser branch February 26, 2024 22:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants