Am Mo., 15. Juni 2020 um 21:50 Uhr schrieb Linus Björnstam <xxxxxx@veryfast.biz>: > > This should not dissuade us from taking a closer look at syntax like > > that of `megacut'. It should encourage us to think of which syntax > > primitives are still missing in the core of the Scheme expander whose > > existing would allow to write `megacut'. > I think one really important aspect is the ability to expand code programmatically. That doesn't address macros below (megacut ...) being dependant on the %x bindings being available at expansion, but I am not really sure how that could be done. Considering syntax-case is highly debated, success with something that would be even more complex and opinionated seems debatable. Why do you mention syntax-case? I think it is orthogonal to the question. We certainly need more than syntax-rules, so it makes sense to look at a procedural macro system, but syntax-case is not the only one (although the most well-thought out one I know of). We may need syntax parameters and identifier macros, but these are orthogonal to the question of the macro transformers. What is still missing, though, is state. While the macros are expanded, the implementation has to record the highest argument number occuring in a megacut use across macro transformer invocations. In other words, we need procedural macros, in which the evaluation order is somehow specified. Another limitation may be that macro transformers never see the macro-expanded code. All this can be done with the much more powerful fexprs (see LISP 1.5 or the Kernel language), but this forfeits compilation. > Recursively scanning code and rewriting bodies is frowned upon for some of the reasons you mentioned, and I doubt there is a good solution to that that isn't a hack. Yes, this would be something like a C preprocessor macro on steroids on the level of S-expressions instead of C preprocessor tokens.
