I think it is dangerous to add this to this SRFI before we have an
idea of how a future keyword standard may look like.

For native keywords, it should be up to the implementation to specify
special support.

Am So., 2. Aug. 2020 um 09:41 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > portable code won't use keywords anyway for now.
>
> You're right. It's not that good to encourage non-portable code. I'm not
> sure whether optional keyword support would do that. Most Schemes don't
> have keyword read syntax, so anyone aspiring to use keywords would get
> stuck with that higher-level problem before we get to specific APIs.
>
> I view the problem as similar to accepting strings vs pathname objects
> for filename arguments (at least Kawa and Racket have such objects).
> Pathname objects are not portable, but that's well known, and they make
> for more idiomatic APIs in the Schemes that have them.
>
> > When we have a keyword srfi we can agree upon, we can make a srfi
> > that enhances srfi-198 with keywords.
>
> I was hoping to avoid that situation :) As far as I can tell, the only
> place we'd need keyword support in 198 is when passing properties to the
> constructor (make-foreign-error or raise-foreign-error). IMHO it would
> be nice to address the situation now rather than write a new SRFI later
> just for this one small change.
>
> It would also allow more idiomatic code in Schemes that already have
> keywords like Gauche, and in a Common Lisp port.
>
> Requiring symbols instead of keywords in `foreign-error-ref` matches the
> CLOS `slot-value` accessor, which also uses symbols
> (http://www.lispworks.com/documentation/HyperSpec/Body/f_slt_va.htm). It
> also respects the convention that each keyword in lambda lists should
> have a matching value (like a property list / plist). (However, this
> latter convention is not strictly enforced in the CL-style keyword call
> convention).