Re:What can we learn from how compilers are designed?
by seanmcdirmid on Friday March 16, 2018 @11:40PM
(#16605492)
You can traverse the AST via internal functions (in OO terminology, virtual methods that make the case matching implicit on this). It really isn't much of a problem if the functions are typecheck, codegen, execute, etc...
I don't really get the appeal of using giant mega case matches in a compiler.
Re:What can we learn from how compilers are designed?
by qznc on Saturday March 17, 2018 @03:12AM
(#16605921)
AST transformations are a exemplary instance of the Expression Problem. Solutions in mainstream languages, eg the Polyglot framework for Java, lead to ugly overengineered code. Writing AST transformations with multimethods might be nice.
Re:What can we learn from how compilers are designed?
by UncleEntity on Friday March 16, 2018 @08:59PM
(#16605050)
There's an essay on this: https://www.gnu.org/software/dotgnu/treecc_essay.html
This means that whatever solution you come up with needs to scale to lots of cases, more than you can comfortably remember. And for a language that's not stable, you need to update all the tools when the AST changes, to handle the new construct.
(Lisp isn't immune; it calls them special forms and they're uniformly represented as lists, but you still have to deal with them for any kind of deep analysis.)