I have taken a look at this implementation. The Chicken implementation
is not a faithful one of SRFI 99 because the generated identifiers
"make-XXX" and "XXX?" cannot be closed in the right syntactic
environment without datum->syntax or some analogous procedure.

It does not have to do anything with ER vs IR-macros.

Chibi's SRFI 99's implementation had the same problem, reported here:
https://github.com/ashinn/chibi-scheme/issues/494.

That was actually the starting point for my syntax-case implementation
in Chibi because I was thinking about how to fix it.

Marc

P.S.: Will Clinger's reference implementation of SRFI 99 is based on
syntax-case and does not have the problem.

Am Mo., 11. Nov. 2019 um 17:48 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> The SRFI--99 implementation for Chicken at <https://chust.org/repos/chicken-srfi-99/artifact/0bc19e89c9f768c6> depends on IR-macros <https://wiki.call-cc.org/man/4/Macros#implicit-renaming-macros>, which are very close to ER-macros but can't be implemented directly on top of them because they need reverse access to the renaming table.  Supposedly IR-macros are just syntactic sugar that can always be rewritten as ER-macros.  Can you take a look?
>
>
> On Mon, Nov 11, 2019 at 9:44 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Am Di., 29. Okt. 2019 um 20:51 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>> >
>> >
>> >
>> > On Tue, Oct 29, 2019 at 1:59 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>> >
>> >> - Keywords being global symbols vs hygienic identifiers.
>> >
>> >
>> > I will believe in the need for hygienic keywords when someone demonstrates a non-hypothetical use for them.
>> >
>> >>
>> >> - Required keyword arguments; default values (other than #f); supplied-p
>> >> parameters ala Common Lisp; combining keywords with optional positional
>> >> args and rest args.
>> >
>> >
>> > I say they are spinach, and I say the hell with them.
>> > <https://en.wikipedia.org/wiki/I_say_it%27s_spinach#/media/File:Spinachbroccolinewyorker.gif>
>> >
>> >>
>> >> - 177 needs to use RnRS-portable read syntax, so we can't use keyword
>> >> objects. That means we need to use either symbols or strings to indicate
>> >> keyword arguments. Symbols would be the natural way to indicate hygienic
>> >> keywords, so it'd be nice to use something else for global keywords.
>> >
>> >
>> > I propose this: if you really must have hygienic keywords, then in systems without keywords, a symbol beginning with ":" is treated as global.
>> >
>> >>
>> >> > Also, if some procedural macro system like `syntax-case' becomes more
>> >> > widespread (say because of inclusion in R7RS-large), we may want to
>> >> > revisit SRFI 177 because it would allow more syntactic freedom when
>> >> > specifying the interface.
>> >
>> >
>> > Can syntax-case give SRFI 177 anything that explicit renaming and define-macro (which is not going to be hygienic) do not?  I agree that having fewer implementations is better.
>>
>> syntax-case has datum->syntax, which explicit renaming does not and
>> makes the latter strictly less powerful. SRFI 99 can be implemented
>> with syntax-case, but not with explicit renaming. I don't see that
>> SRFI 177 needs datum->syntax, but we haven't agreed on/seen the final
>> proposal for its syntax.
>>
>> >
>> >>
>> >> The troubles with this SRFI may be a good argument for why there should
>> >> be a standard lower-level macro system lke syntax-case :)
>> >
>> >
>> > If Marc's Chibi library can be made to cover Chicken, Gauche, and MIT (which will need patches for each one), I'd say that making syntax-case a standard is feasible.
>>
>> This also seems to be in line with WG2's charter: "... When deciding
>> which features to include in the language, working group 2 should
>> consider all features provided by R6RS Scheme, and all criticisms of
>> those features. Insofar as practical, the language should be backwards
>> compatible with an appropriate subset of the R6RS standard..."
>>
>> This does not make it mandatory to include `syntax-case' in
>> R7RS-large, but there should be a good reason not to include it if a
>> low-level system is going to be included. (With R7RS-large and beyond,
>> we may still hope that R7RS+ and R6RS can converge again some day.)
>>
>> >
>> >>
>> >> 177 is explicitly designed so that other libraries' *interfaces* never
>> >> depend on it. It's only a dependency for the library *implementations*.
>> >> If a better syntax for keywords is found later, then the implementations
>> >> can gradually be converted to use that instead, while their interfaces
>> >> stay intact. 177 is meant to be an implementation detail, and to
>> >> co-exist and interoperate with all present and future keyword systems;
>> >> not to replace them.
>> >
>> >
>> > I don't understand that. If a portable R7RS-large library wants to expose procedures that have keywords (and I'd like that), then it has to use either SRFI 177 conventions or some other conventions.
>> >
>> >>
>> >> The problem is that keyword arguments serve a real need; in their
>> >> absence people use alists or plists, which are *guaranteed* to be
>> >> unhygienic, non-type-checkable and non-optimizeable. With any keyword
>> >> system at all, a Scheme implementation has the possibility to do better
>> >> than the current situation.
>> >
>> >
>> > +1.  I have carefully avoided the need for them in R7RS-large so far, but SRFIs and pre-SRFIs are now starting to appear that simply have too many options to be handled as standard Scheme arguments.
>> >
>> >
>> >
>> > John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
>> > And now here I was, in a country where a right to say how the country should
>> > be governed was restricted to six persons in each thousand of its population.
>> > For the nine hundred and ninety-four to express dissatisfaction with the
>> > regnant system and propose to change it, would have made the whole six
>> > shudder as one man, it would have been so disloyal, so dishonorable, such
>> > putrid black treason.  --Mark Twain's Connecticut Yankee
>> >
>>
>>
>> --
>> Prof. Dr. Marc Nieper-Wißkirchen
>>
>> Universität Augsburg
>> Institut für Mathematik
>> Universitätsstraße 14
>> 86159 Augsburg
>>
>> Tel: 0821/598-2146
>> Fax: 0821/598-2090
>>
>> E-Mail: xxxxxx@math.uni-augsburg.de
>> Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/

--
Prof. Dr. Marc Nieper-Wißkirchen

Universität Augsburg
Institut für Mathematik
Universitätsstraße 14
86159 Augsburg

Tel: 0821/598-2146
Fax: 0821/598-2090

E-Mail: xxxxxx@math.uni-augsburg.de
Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/