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.