A few questions Vladimir Nikishkin (28 Sep 2020 01:56 UTC)
Re: A few questions Marc Nieper-Wißkirchen (28 Sep 2020 07:29 UTC)
Re: A few questions Adam Nelson (28 Sep 2020 18:38 UTC)
Re: A few questions Marc Nieper-Wißkirchen (28 Sep 2020 18:46 UTC)
Re: A few questions Alex Shinn (30 Sep 2020 00:45 UTC)
Re: A few questions Marc Nieper-Wißkirchen (30 Sep 2020 06:30 UTC)
Re: A few questions John Cowan (28 Sep 2020 19:23 UTC)
Re: A few questions Marc Nieper-Wißkirchen (28 Sep 2020 19:53 UTC)

Re: A few questions Marc Nieper-Wißkirchen 28 Sep 2020 18:45 UTC

Am Mo., 28. Sept. 2020 um 20:37 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:
>
> +1 for defmacro (more often spelled define-macro in Scheme), because a
> lot of Schemes only have that, and my experience in Schemepunk has been
> that I sometimes have to drop into defmacro to write portable code for a
> few Schemes that have broken syntax-rules/syntax-case implementations.

Consider it added, then.

More explicitly, I would add:

(define-macro name transformer)
(define-macro (name . formals) body)
(lisp-transformer proc)

Here, proc takes an s-expression and returns one, so
er-macro-transformer without rename and compare.

What library name do you suggest?

The first that comes to my mind is (srfi 211 lisp).

Marc

PS In case you extend Schemepunk to Unsyntax, please report any bugs
you may find.

>
> On 9/28/20 3:29 AM, Marc Nieper-Wißkirchen wrote:
> > Hi Vladimir,
> >
> > thank you for your input!
> >
> > Am Mo., 28. Sept. 2020 um 03:57 Uhr schrieb Vladimir Nikishkin
> > <xxxxxx@gmail.com>:
> >> Hello,
> >> Thank you for your job!
> >>
> >> I just had a few questions about this srfi.
> >>
> >> 1)If its main aim is to define standard library names, would it not be
> >> worth including (srfi 211 defmacro) for legacy macros, and (srfi 211
> >> syntax-rules) for the r7rs macros?
> > We already have (scheme base), which exports syntax-rules, so I don't
> > see the need for a library alias just for syntax-rules. (Strictly
> > speaking, this is also true for (srfi 211 syntax-parameter), for which
> > we already have (srfi 139), but the latter is not a standard R7RS
> > (small) library.)
> >
> > I can add a defmacro library for those Schemes that do not provide any
> > of the other libraries. Does Guile
> > (https://www.gnu.org/software/guile/manual/html_node/Defmacros.html)
> > document an established standard for defmacro in the Scheme world?
> >
> >> The first could provide a helpful error message urging users to update
> >> their code on systems that do not want to support defmacro, and the
> >> second one would be a no-op on r7rs systems, and would actually
> >> provide syntax-rules on the non-r7rs systems.
> > Which systems do have R7RS libraries but not syntax-rules? Already R5RS had it.
> >
> >> 2)There are no procedures or syntax doing any sort of macro expansion.
> >> Almost all implementations, however, do provide some form of
> >> macroexpand, macroexpand-1, macroxpand:eval.
> >> SLIB lists those for almost every macro system:
> >> https://people.csail.mit.edu/jaffer/slib/Scheme-Syntax-Extension-Packages.html#Scheme-Syntax-Extension-Packages
> >> Are they clearly out of scope for this SRFI?
> > Is there clear semantics of these procedures? In general, full macro
> > expansion does not produce some s-expression but some internal ast
> > (which may be represented by an s-expression, of course).
> >
> > Thanks!
> >
> > Marc