Am So., 15. März 2020 um 17:37 Uhr schrieb Lassi Kortela <
xxxxxx@lassi.io>:
> Could you briefly describe what you mean by hygiene or what you would
> like to have explained?
Thanks for asking :)
Basically everything we've covered so far... at least:
- The problems with the hack of parsing specially-named symbols as
keywords (e.g. doing symbol->string to figure out that :foo stands for
the keyword "foo").
What we are looking for here is a new type of syntax in the lexical structure described in section 7.1.1 of R7RS-small, namely a syntax for keywords. To truly implement such new syntax, the Scheme reader has to be modified. (While this should be easy for all implementations, it would break compatibility with R7RS-small.)
The "hack" of parsing specially-named identifiers cannot faithfully implement what has to be implemented in the reader. While it may work most of the time, it is no viable solution: A macro like `call/kw' that uses `symbol->string' to parse identifier names can be the result of a macro expansion itself. The macro expansion process may insert identifiers like `:foo' into a `call/kw' macro use, where these identifiers come from other parts of the program where they stand for variables and not keywords, causing the macro to break.
This is not transparent to a user: If a library `(bar)' exports macros and uses SRFI 177 with such a hack internally, code using `(bar)' mustn't use identifiers like `:foo' either although that code may not have anything to do directly with SRFI 177. So, in some sense, SRFI 177 with this hack will taint the whole program and not only individual libraries using it directly.
It would also not only be a problem with a specific implementation. If SRFI 177 was specified so that identifiers whose name reads as `:foo' are to be interpreted as keywords, every implementation which is conforming to R7RS-small *has* to use this hack, making the specification of SRFI 177 rather muddy.
Given `(call/kw a b c d)', we wouldn't know until after expansion which arguments are keywords and which are arguments.
- What keyword argument semantics / syntax are within the realm of
possibility for R7RS-large. (Or what options are easy/likely, what are
hard/unlikely.)
I will write more about this later.
- Which keyword call / define-keyword syntaxes would play along best
with hygienic keyword arguments, and which would cause problems.
If we want keywords to behave like the auxiliary syntax `=>' and `else' in the derived expression forms of R7RS, any "procedure" taking keyword arguments has to be a macro itself. Using identifier syntax, such a "procedure" can have a first-class value that is a true procedure, but this ordinary procedure would not be able to take keyword arguments.
- How to define hygienic keyword arguments in libraries so exporting
them to other libraries doesn't confuse newbies.
Auxiliary syntax in syntax-rules macros are matched using `free-identifier=?'. Given two identifiers, `x' and `y', they are free-identifier=? if they either denote the same thing or are both unbound.
The usually auxiliary syntax `=>' and `else' is bound to something in `(scheme base)'. So if you want your `else' or `ELSE' to work with the `cond' of `(scheme base)', your `else' or `ELSE' has to be bound to the value, the `else' of `(scheme base)' is bound to.
What we could agree on for "hygienic" keyword is that the are matched by `free-identifier=?' but that we do not bound identifiers of the form `:foo'. Then they don't have to be exported by any library and will match by name. And if you need an unforgeable keyword or one that is guaranteed to be disjoint to any other, you can (by convention!) choose an identifier not beginning with `:' and bind it to some value.
- How allow-other-keys is currently implemented in some Lisps/Schemes,
and how it could be done differently.
Lots of stuff, but we can write collaboratively to lighten the load.
This document could inform the R7RS-large decision-making process as well.
P.S.: The R7RS-small uses the technical term "keyword" in a different sense. We may want to find a new term for SRFI 177-"keywords", otherwise the R7RS-large document may have keywords of two very different kinds.