Email list hosting service & mailing list manager

macroexpand SRFI? Lassi Kortela (03 Oct 2019 15:30 UTC)
Re: macroexpand SRFI? Marc Nieper-Wißkirchen (03 Oct 2019 15:40 UTC)
Re: macroexpand SRFI? Arthur A. Gleckler (03 Oct 2019 18:43 UTC)
Re: macroexpand SRFI? John Cowan (03 Oct 2019 20:20 UTC)
Re: macroexpand SRFI? Marc Nieper-Wißkirchen (03 Oct 2019 20:36 UTC)
Re: macroexpand SRFI? Lassi Kortela (04 Oct 2019 10:29 UTC)
Re: macroexpand SRFI? Vladimir Nikishkin (04 Oct 2019 07:45 UTC)
Re: macroexpand SRFI? Marc Nieper-Wißkirchen (04 Oct 2019 08:14 UTC)
Re: macroexpand SRFI? Shiro Kawai (04 Oct 2019 10:11 UTC)
Re: macroexpand SRFI? Shiro Kawai (04 Oct 2019 10:14 UTC)
Re: macroexpand SRFI? Lassi Kortela (04 Oct 2019 14:17 UTC)
Re: macroexpand SRFI? Amirouche Boubekki (04 Oct 2019 09:18 UTC)
How hard is a portable macroexpand only for display purposes? Lassi Kortela (04 Oct 2019 10:26 UTC)
Re: How hard is a portable macroexpand only for display purposes? Marc Nieper-Wißkirchen (04 Oct 2019 11:28 UTC)
Re: How hard is a portable macroexpand only for display purposes? Marc Nieper-Wißkirchen (04 Oct 2019 15:01 UTC)

How hard is a portable macroexpand only for display purposes? Lassi Kortela 04 Oct 2019 10:26 UTC

Thanks to everyone for the thoughtful comments! Some of the advanced
stuff went over my head. I'll have to do some studying :)

Personally I would be content with a portable macroexpand that simply
shows some Scheme syntax that's nice to view in the REPL so you can find
out whether the macro is expanding to the code you expect. Common Lisp
has a standard `macroexpand-1` for this purpose and it's supremely
convenient.

The precise naming of identifiers in the output due to hygiene,
environments and other concerns probably doesn't matter for this
purpose. And it doesn't matter whether the output can be evaluated in
the REPL; it's enough to be able to view it. After all, we can always
evaluate the macro by inputting it without the (macroexpand ...) around
it. The output cannot be the same in every Scheme that implements the
SRFI, and that's perfectly fine. It doesn't matter if things like `case`
expand to different primitive forms in different implementations, etc.

Of course if someone wants something more ambitious, I wouldn't stop them :)