Le jeu. 3 oct. 2019 à 17:30, Lassi Kortela <xxxxxx@lassi.io> a écrit :
>
> 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?

I am still a newbie. So forgive my clueless dreams.

As second Lassi, it would be nice to have a macroexpand procedure in
the spirit of alexpander.scm or Chez Scheme expand [0].

[0] https://cisco.github.io/ChezScheme/csug9.5/system.html#./system:s82

Chez Scheme signature is the following:

  (expand obj env)

Where obj is datum or syntax obj. To that I would add an optional argument
that specify whether the output will be datums or syntax objects which
constructor
is provided as argument too. Another option could be whether the expander does
optimize the datums. In the case of Chez, expand will turn (cons a b)
into (#$cons2 a b).

Use cases:

1) My first use case, is preprocessor for skribe syntax. skribe
expression are read using
a specific read procedure that outputs regular scheme datum (without
square brackets).
At this point the scheme expression, contains things like:

  (define-procedure (hashmap-clear hashmap) "Delete all elements")

I would like the  expander to generate something like the following sxml:

  (div
    (h2 (@ (class "definition procedure")) (code "(hashmap-clear hashmap)")
    (p "Delete all elements"))

Of course you can achieve something similar with a meta-evaluator, that you
would anyway need to handle things like section numbering etc...

2) My second use case is a Scheme to JavaScript compiler. I started such
a thing and I rely on Chez expand to support the module system and syntax-case.
BUT Chez expand does optimize SOME stuff which lead to complicated code [1]

[1] https://github.com/scheme-live/ruse-scheme/blob/dd480e17edd9a233fd2bc4e8b41ff45d13fcc328/rusec.scm#L616-L647

Again, this will be NICE, but I don't think that is a priority.

--
Amirouche ~ amz3 ~ https://hyper.dev