On Mon, 15 Jun 2020, at 22:08, Marc Nieper-Wißkirchen wrote:
> 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.

because imo it was a clear benefit, but still was rejected by many (which is fine, but that is another discussion). A macro system that can reliably implement megacut in a composable and nice way is going to be an even bigger change - which will probably be more diversive.
>
> 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.

And therein lies the problem: if a macro can expand it's body and then maybe add identifiers, the inner macros can't depend on the environment they are expanded in being fixed. You have probably spent a lot more time thinking about this than i have, so I am curious what you think: At what point do we say "this is adequate"? Auc procedural macro system which can expand code below it is clearly within reach of most schemes (I already have it mostly working for guile), and will get us pretty far. But it will not be very resilient if the macros you are expanding are relying on being able to inspect bound identifiers and such.