This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 516: The lack of a fully-featured macro system requires sub-par constructs

2013-07-07 03:20:44
WG1 - Core
2013-05-13 09:03:36

Aaron Hsu writes:

By requiring that we work in certain constraints (the lack of a full featured macro system, for instance) necessitates the use of sub-par constructs which are more complicated, the complication of which needed to exist only in the absence of more general, and more expressive forms. Contrary to the nature of simplicity and elegance, I believe that much of what WG1 has accomplished is to use patches on a self-constrained system, resulting in features piled on that could easily have been removed or more cleanly implemented in the presence of more general and expressive features. If WG2 could do it better with more expressive features, then why should WG1 duplicate features in a more ugly and less clean manner that does not scale as well just to have them? Rather, the correct approach would have been to allow implementations who wanted such features to use WG2 features that were designed. Unfortunately, we will likely now have a set of overlapping features implemented in WG2, and this doesn’t do anyone any favors.

There are a lot of fully-featured macro systems around, and WG1 believed that none of them were appropriate for the small language, bringing in as they do considerations of phasing. There is no reason why the large language cannot provide more than one.

To clarify here. My complain stems not from WG1 resistance to a full-featured macro system, but rather, in the choice to standardize forms which only appear necessary because of the lack of said macro system. Better to have not standardized what WG2 could standardize better than to standardize a less elegant solution now, with the very strong likelihood of having additional functions to do the same thing more elegantly later in WG2.

It's this sort of thing which kept syntax-rules out of IEEE and R4RS, only to have it standardized years later with essentially no changes. Contrary to popular belief, something once standardized in RnRS is not necessarily standardized forever, though there is certainly a presumption in that direction that standardizers should respect: see StandardsIncompatibilities for the changes between R2RS and R5RS.

What's more, I don't think our library declarations are particularly inelegant at all.


The WG decided by unanimous consent to take no action on this ticket.