Poor man's implementation of SRFI 206 Marc Nieper-Wißkirchen (16 Aug 2020 09:48 UTC)
Re: Poor man's implementation of SRFI 206 Arthur A. Gleckler (18 Aug 2020 18:04 UTC)
Re: Poor man's implementation of SRFI 206 Felix Thibault (19 Aug 2020 15:09 UTC)
Re: Poor man's implementation of SRFI 206 Marc Nieper-Wißkirchen (19 Aug 2020 14:35 UTC)
Re: Poor man's implementation of SRFI 206 Felix Thibault (19 Aug 2020 21:17 UTC)
Re: Poor man's implementation of SRFI 206 Marc Nieper-Wißkirchen (20 Aug 2020 05:36 UTC)
Re: Poor man's implementation of SRFI 206 John Cowan (20 Aug 2020 17:02 UTC)
Re: Poor man's implementation of SRFI 206 Marc Nieper-Wißkirchen (20 Aug 2020 18:58 UTC)
Re: Poor man's implementation of SRFI 206 Felix Thibault (20 Aug 2020 20:23 UTC)
Re: Poor man's implementation of SRFI 206 Marc Nieper-Wißkirchen (20 Aug 2020 20:30 UTC)

Re: Poor man's implementation of SRFI 206 Marc Nieper-Wißkirchen 20 Aug 2020 18:58 UTC

Am Do., 20. Aug. 2020 um 19:02 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> _ banned explicitly in R6RS

Not banned, but not easily matchable with an R7RS-conformant implementation.

> ... OK because a peculiar identifier

This has the same problem as _ for R6RS, I think.

PS Contrary to what I said before, _ (and ... as well) are actually
matchable with syntax-rules even if they don't appear as part of the
list of literal identifiers. First, check with the usual tricks that
some input element is an identifier and then expand into a macro that
uses that element as part of the pattern and template and which
behaves differently (but well-defined) whether the inserted element is
_ or not. The same holds true for ....