Closed anshumanmohan closed 4 months ago
Sounds good to me! Should make my job with the interpreter easier.
Super, thank you both! Gonna go ahead and merge then. And yes, @csziklai, I think this will force the user to write "nice" programs more often, so that should be helpful to you! Also, we now actually parse and generate a prog
of type Ast.program
, and I suspect that will save us from some grief later on 😅
One drive-by thought: The declaration/statement distinction is something Dahlia also has but one thing it suffers from is bad error messages. If declarations and statements are interleaved, the parser just says "parser error". I would recommend adding an error rule in the parser that successfully parses a declaration after a statement and then immediately throws an error.
27 is about to be closed, but I have a little more simplification to offer in the AST. I'd love feedback on this from all. This PR makes the changes I propose below, both in the AST and in the parser. It works correctly on all our sample programs.
However, please treat the text below and the PR itself as a proof of concept. It's not trying to be "set in stone" or prescriptive in the slightest; please do chime in with your thoughts.
At present we have:
Since we have a statement list, we don't really need a
Seq
constructor instatement
. We just need to actually parse a list of statements as a list, not aSeq
. If we take on that responsibility at the parser level, our AST gets to be a little simpler:We should probably also drop the
| Declare of declare
constructor fromstatement
, so that the user gets exactly one chance to declare their classes up top. That gets us to:In the same spirit you may want to drag
return
out into its own type, such that the user can only have onereturn
at the end of the program.And now you observe that
statement
is nothing more than a silly wrapper forAssignment
, so why not just changestatement list
intoassignment list
and be done with it?