In Gauche, full macro expander yields an internal form which is not a first-class object in Scheme.   We have a few

flavors of macroexpand-type API to help debugging, but their results are just for information to humans and

not expected to be reused in the program---e.g. you can't always tweak the result of macroexpand in Scheme

and then put it back to the compiler pipeline, like Common Lisp.

If the macroexpand srfi requires such kind of flow, it'll be difficult for us to support in Gauche.

On Thu, Oct 3, 2019 at 10:14 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

Am Fr., 4. Okt. 2019 um 09:45 Uhr schrieb Vladimir Nikishkin <xxxxxx@gmail.com>:

I wouldn't mind having a standard name for a macro-to-procedure converter, even if its semantic or even the result is not specified.

It may work across a number of Scheme systems if, say, "macroexpand" becomes a special form "(macroexpand <stx>)" and not a procedure. When "(macroexpand <stx>)" is evaluated, the form <stx> is fully macro-expanded in the current syntactic context, and the syntax object resulting from the expansion is the value of the "macroexpand" special form.

Here, it will be implementation-defined what a "syntax object" is, e.g. it could be a syntactic closure or an R6RS syntax-object. By fully macro-expanded, I mean that the resulting syntax object does not represent a user-defined macro of the form "(<keyword> ...)" and no user-defined identifier macro of the form "<keyword>".

Marc

 

I think that would make writing an IDE for scheme easier. At least in the sense that if the questioned scheme system doesn't support macro expansion, then the dysfunctional GUI elements could be hidden.

On Thu, Oct 3, 2019, 22:30 Lassi Kortela <xxxxxx@lassi.io> wrote:

Has someone here by chance written a pre-SRFI for macroexpand (or
macro-expand, syntax-expand, etc.)? Would be nice to have a standard way
to find out what code your macros expand to.

Since Scheme has several macro systems (syntax-rules, syntax-case,
CL-style define-macro, maybe others?) does that complicate the interface
of a macroexpander, or is the complexity all in the internals?