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

Membership expressions #13

Open
darrylabbate opened this issue Oct 31, 2022 · 2 comments
Open

Membership expressions #13

darrylabbate opened this issue Oct 31, 2022 · 2 comments
Labels
feature New feature or request language Language features/requests
Milestone

Comments

@darrylabbate
Copy link
Member

darrylabbate commented Oct 31, 2022

Currently, in is only supported in for loops. in can be added as an infix operator (membership, pattern matching, etc); valid in any expression. Support for not in would need to be implemented as well.

Precedence level should be lower than ~ and .. but higher than &&

@darrylabbate darrylabbate added feature New feature or request language Language features/requests experimental Purely experimental ideas (for now) labels Oct 31, 2022
@darrylabbate darrylabbate changed the title in as a standard infix operator Membership expressions Nov 2, 2022
@darrylabbate darrylabbate added this to the Riff 0.4 milestone Nov 18, 2022
@darrylabbate
Copy link
Member Author

darrylabbate commented Nov 27, 2022

Type dispatch:

  • If y in the expression x in y can be coerced to string, x in y should essentially be the inverse of pattern matching (i.e. y ~ x).
  • If y is a table, x in y evaluates as true if the value x (not key) is somewhere in the table.
  • If y is a range, assert x is an integer (or float equivalent) and falls in the range. I.e. x in a..b:c == $\lbrace x|x\in c\mathbb{Z}, a \leqslant x \leqslant b \rbrace$

For all other types, it should follow whatever rules the pattern matching operation enforces.

@darrylabbate
Copy link
Member Author

darrylabbate commented Dec 5, 2022

Precedence level should be lower than ~ and .. but higher than &&

Not currently possible to be lower than .. but also higher than &&. Logical operators should probably be lowered s.t. a in b..c && x in y..z does what you'd expect. .. was originally given very low precedence since its only real uses were for loops and substring extraction.

@darrylabbate darrylabbate modified the milestones: Riff 0.5, Riff 0.4 Dec 9, 2022
darrylabbate added a commit to darrylabbate/aoc that referenced this issue Dec 10, 2022
darrylabbate added a commit to darrylabbate/aoc that referenced this issue Dec 10, 2022
@darrylabbate darrylabbate removed the experimental Purely experimental ideas (for now) label Dec 26, 2022
@darrylabbate darrylabbate pinned this issue Dec 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request language Language features/requests
Projects
None yet
Development

No branches or pull requests

1 participant