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/