-
Notifications
You must be signed in to change notification settings - Fork 356
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 Grammar documentation #266
Conversation
The original definition is wrong, since generic lists can also have generic type packs (...)
We should rename TypeAnnotation to Type (incl SimpleTA etc.); we used to use TypeAnnotation in the AST names but it's actually a bit misleading because "annotation" refers specifically to ": Type" syntax, e.g. in |
This should also include the more recent changes wrt type packs, see https://luau-lang.org/typecheck#type-packs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Our grammar in Parser.cpp by and large is dated and incorrect, so there's some things to tie up on.
bindinglist
is Luau's version of Lua's namelist
. I think it deserves its own name specifically because it has type annotations. Maybe we should add a comment? The syntax for that in EBNF is (* ... *)
.
I think we want to use exp
specifically to be consistent with Lua's original grammar, but we do use expr
very often outside of this EBNF.
I'll review the rest of this next week.
Co-authored-by: Alexander McCord <11488393+alexmccord@users.noreply.github.com>
Into `prefixexp`, `var` and `functioncall`. Same as Lua5.1+
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I'm going to merge this as I think this is pretty accurately depicting the Luau grammar. Would be fun to get some generator that can use EBNF directly and see if we have omissions here but we can always correct issues if found later.
Just wanted to point out I haven't implemented the type pack syntax yet that you mentioned (unfortunately been busy with some other stuff rn). I don't know if you want to just merge it now anyways or wait until that's done (I need to look into it more). |
Thanks - I think it's fine to merge this as is because we'll need tweaks to generic arguments anyway following the newer updates for default values. Maybe @vegorov-rbx can help with this? In the meantime I've added a note to the page that documents the omission. |
This PR adds grammar documentation to the webpage (closes #148)
I got the initial definitions (available in the initial commit) from the comments in https://github.com/Roblox/luau/blob/master/Ast/src/Parser.cpp.
Subsequent commits deal with including definitions which were missing, fixing incorrect definitions, and tidying up the definitions. I've tried to break it up into small commits so you can see the changes I made against the initial definitions in the Parser.cpp file - you may want the comments updated in Parser.cpp in a different PR.
A few things of note:
bindinglist
is a strange one, it has the option to allow 3 dots depending on what we are parsing, which isn't something I can express in EBNF (to my knowledge). I was kinda confused what the 3 dots were about, I think its for the...
vararg in a parameter list? but thats also described inparlist
, so I'm not entirely sure. I took thebindinglist
definition from the comments in Parser.cpp, but it is also used in local declarations and for loops, so it doesn't really fit right now.functioncall
, it seems to be a subpart ofprimaryexp
, but primaryexp also contains normally indexing. I wasn't sure whether to break it down like in Lua5.1/5.4, as I didn't want to deviate from how it works internally.exp
orexpr
?STRING
orString
for terminal nodes? all lower case vs. PascalCase for definitions (PascalCase seems to only be used for type-related definitions?). I've normalised (most) of them to be consistent, but maybe you want it a bit different.I've worked my way through Parser.cpp to come up with the document, but I'm bound to have missed something. Let me know if there's a mistake somewhere!