BYU - Spring 2013 - CS 630 - 6/13 - Paper
Andrew Kent
Honu!
This paper is about how all the work that has gone into Lisp/Scheme/Racket macro development over the last 20 years is so powerful that it can even support and be applied within an infix based language to create a C-like language with macro extensions. This is quite an amazing feet, but is not without its costs (expressiveness).
Honu was designed the way it was to find a sort of middle ground between syntactic minimalism, and expressiveness, and the grammatical freedom. It uses Racket to build an infix-notation language, resembling C or Javascript, that is radically different because it supports the powerful, easily defined and used macros that we have been learning about in this course thus far. To illustrate this they give a quick example of a derivative and parabola macro and show how they work.
Like Racket, syntax classes are also supported in Honu, allowing for more concise, expressive, and clear definitions of macros. Ellipses are also supported. Okay, so they’re very similar to Racket macros (although I didn’t see some of the more complex, local-syntax, syntax-parse, etc... I guess I mean to say I did not see a large variety of flavors as I was looking at the macros they showed - they all seemed related in form).
They then move on to explaining how some of the infix reasoning is done (specifically regarding the precedence). Honu operators have a name, precedence, associativity-direction and whether it is a binary, unary, or both transformation. It becomes apparent during this section the number of additional things that must be tracked and managed when using infix notation as opposed to the more clear, more verbose prefix notation of Racket and family.
The paper got into how parsing Honu works - there are 3 layers of parsing: a reader, enforestation, and parsing. The Reader produces terms (as opposed to fully parsed ASTs) and these are more easily extended syntactically. The enforestation phase extracts the terms and creates a tree term - the process of enforestation is controlled by the above mentioned precedence of operators. The final phase, parsing, is done in several passes as well. Having a 2 pass parser allows for mutually recursive definitions. The first pass grabs the signatures/declarations in the enclosing scope until all are registered and the second pass delves into their bodies. Man, I wish more languages did this - I hate it when I forget I’m in a language that cares what order I declare functions in and have to rearrange the file to please the parser.
They show in the parsing section how the flexible ordering and placement of macro bindings allows for some pretty cool language extensions, like the contracted macros/functions they give as an example (cfun).
They show how parsing is handled, progressively consuming and enforesting the terms in expressions until all are gone.
At the very end of the paper they talk about numerous examples of similar systems. They note the C++ templates are the most successful language-extension mechanism outside of the land of lisp. Although there are some similarities, the templates in C++ are far less expressive and flexible when compared to Honu, and they are limited to only pattern matching. It is interesting to think of the templates in C++ as related to macros. Macros have proven to be a huge way more powerful concepts can be explored in programming langauges. In what I have seen in industry with C++ templates, they are able to provide some features and functionality that is incredibly unique and powerful, and thus in the hands of skilled systems architects they can be used in quite creative ways to solve problems. This is not to say they are “really” comparable to Racket/Honu macros, but maybe looking at them through this light of “wow, *real* macros are awesome” gives some insight into some of the less obvious reasons (or less thought of reasons, for me) why they are so useful in certain situations. They allow for extensions and problem solving that the core language itself cannot provide (though very limited), and this is inherently a powerful idea!
Questions:
Honu macros are limited in the way they can express things - their syntactic simplicity only accommodates syntactic extensions that fit certain conventions. How would you characterize the realm of macros it cannot support? Only odd, esoteric ones? A large set of the ones commonly used in Racket? I didn’t get a feel for how limiting this was in the paper. Maybe we can do an example and/or discuss in class one that shows the limitation and I’ll have a better feel?