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.
 
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.
 
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