From c404d146892b314870312b3b51100c352a4c8b24 Mon Sep 17 00:00:00 2001 From: Mike Hewner Date: Mon, 29 Jan 2024 15:19:37 -0500 Subject: [PATCH] clarifying the importance of syntax expand --- Homework/Assignment_14/Readme.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Homework/Assignment_14/Readme.md b/Homework/Assignment_14/Readme.md index b08143a..5f59c29 100644 --- a/Homework/Assignment_14/Readme.md +++ b/Homework/Assignment_14/Readme.md @@ -24,6 +24,8 @@ To make your interpreter work with the test cases add this to your file: - Whatever additional primitive procedures are needed to handle the test cases I give you. This requirement applies to subsequent interpreter assignments also. - syntax-expand allows you (but not necessarily the user of your interpreter) to introduce new syntactic constructs without changing eval-exp. Write syntax-expand and use it to add some syntactic extensions (at least add begin, let*, and, or, cond). You do not have to implement “named let” until assignment 16. +Note that syntax-expand (as described below) is a REQUIREMENT of this milestone, and more importantly of later steps including Exam 2. Do not come up with some alterative design that does syntax expansion as a side effect of parsing, especially do not call syntax expand from eval-exp. Syntax expand should be a function that takes abstract syntax trees from parse-exp, transforms them into other abstract syntax trees that only include "core" forms, and then that result is passed to eval exp. + I suggest that you thoroughly test each added language feature before adding the next one. Augmenting unparse-exp whenever you augment parse-exp is a good idea, to help you with debugging. But be aware that after you have syntax-expanded an expression, unparse-exp will no longer give you back the original, unexpanded expression. However, unparse-exp can still be very useful for debugging. **A more detailed description of what you are to do:** @@ -100,7 +102,7 @@ You will need to modify eval-one-exp (and perhaps rep as well) to include syntax Look at Flow.png -Note that it is acceptable, and perhaps more efficient, to "mix up" parsing and syntax expansion (having parse-exp call syntax-expand and vice-versa), but this can make debugging harder, so I do not recommend it. First parse the code, then syntax expand, then evaluate. This is a suggestion, not a requirement. +More sophisticated expansions might "mix up" parsing and syntax expansion (having parse-exp call syntax-expand and vice-versa), but I am going to require that you do not use this approach. First parse the code, then syntax expand, then evaluate. *Aside: Think about what the code for syntax-expand would be like if it were written as a pre-processor to the parser, rather than a post-processor as in the above code. This will increase your appreciation for having the interpreter use abstract syntax trees instead of raw, unparsed expressions!*