> On Jul 21, 2019, at 00:19, Matthew Flatt <mfl...@cs.utah.edu> wrote: > > I have in mind "Honu: Syntactic Extension for Algebraic Notation through > Enforestation", GPCE 2012. It shows how we can bridge the relatively linear > structure of non-() programs to the tree structure of S-expressions. > Specifically, the bridge is called "enforestation". It sits roughly between > the reader and the expander, but enforestation needs to be interleaved with > expansion to get the level of expressiveness that Racketeers would expect.
To add a few of my own thoughts on this: in light of recent events, I reread the Honu paper more closely this past week, and I would strongly encourage anyone who is invested in surface syntax to do the same. It is a beautiful paper. Crucially, it is beautiful not because it does anything complex but because it solves a hard problem in a simple, elegant way. If you have any misgivings about what might happen to the expressiveness of the macro system if we were to move away from s-expressions, it is required reading. What the paper does not do is editorialize (as it shouldn’t), so I will do so myself. The techniques described in the Honu paper are dramatically superior to alternative approaches I have seen, for two reasons: “Automatic parenthesis insertion” approaches like sweet, wisp, liso, etc. invariably demand users think about the desugared, parenthesized form. Macros are ultimately still defined by parsing syntax objects built from s-expressions, so every extra pair of parentheses suddenly matters, even if they’re invisible and no reasonable built-for-purpose syntax would care about them. This is a terrible experience, and it forever condemns these approaches to be second-class citizens. Honu’s macros, in contrast, operate much closer to the concrete syntax, and they don’t require thinking about implementation details of the language. We demand our Racket macros be real abstractions, and Honu lets them stay that way. It is easy to foresee a transition away from s-expressions as a restriction on what can be expressed via macros, mostly since non-s-expression languages with macro systems (such as Haskell and Elixir, to name just two) usually impose such restrictions. But that is what is so remarkable about Honu: its macros allow what is really a superset of Racket’s current syntactic flexibility. I think the paper has a good explanation of why this is, I just don’t think it points out the implications explicitly enough, so if this is a surprise to you, go back and take another look. Of course, it’s not all roses. The existing Honu implementation lays sturdy foundations, but it doesn’t include a syntax/parse equivalent: there’s no Honu-native DSL for writing Honu macros. A lot of the ideas in syntax/parse should carry over, but there are more than a few new wrinkles to be ironed out. On top of that, there are open questions about everything from documentation to tooling to what the appropriate syntax for the base language ought to be. I understand that many people in the Racket sphere are very fond of s-expressions for a variety of reasons, something that was made abundantly clear to me in the several dozen replies I got to a twitter comment I made on the matter. <https://twitter.com/lexi_lambda/status/1152171606648786945> I certainly can’t assuage all fears of losing them, but I sincerely hope that the second point I made above sinks in for others like it has for me: there are ways a change in syntax can be enabling, not simply a compromise for some non-specific “other people.” Wouldn’t it be wonderful if we could design new languages, embedded or otherwise, with whatever syntax we wish as easily as we can design them in Racket today using s-expressions? Going down this path has the potential to move us much closer to that reality, and I, for one, think that’s exciting. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/FE3BEE8D-4380-4540-B478-F0BB424A5C4E%40gmail.com.
