On 13 Jun 2021, at 00:08, John Cowan <xxxxxx@ccil.org> wrote:

> On Thu, Jun 10, 2021 at 6:17 AM Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
>
>> Thanks for the info. I'm not very good with Docker but I'll take a look.
>
> If you have Docker installed, then typing "docker run -it schemers/chicken" will start you up in csi, and similarly for "chezscheme", "bigloo", "oaklisp", etc. etc.

Ahh, thank you. I was missing the -it argument initially.

>> Reading bare : as a keyword seems like a bug to me, at least if keywords are disjoint. The keyword with an empty name should be spelled ||: or :||, by analogy to the symbol with an empty name.
>
> Agreed, but as you say the point is compatibility.

Nonetheless, I'll see about opening bugs in Gauche, Sagittarius, and STklos to get this fixed. (I've also noted a bikeshed issue to find a new name for the `:` macro. But ideally, imo, we have a system where such a macro isn't necessary anyway.)

>> From another practical standpoint, though, as mentioned, even optimized implementations sometimes need to do keyword binding at runtime, at least if first-classness is maintained,
>
> It depends, I suppose, what you mean by "first-class".  If you treat (foo :zam 10 :bar 20) as syntactic sugar for (foo% 20 10), then foo% is a first-class procedure.

Sure, but foo should ideally be first-class as well. If a procedure takes both positional and keyword arguments, and all of the latter are optional with some sensible/desirable defaults, it would be surprising (and annoying) *not* to be able to pass that procedure as the first argument to map, say. Losing first-classness of foo itself undermines the idea mentioned in the rationale that optional and named parameters are ways to allow library procedures' behaviour to be extended while maintaining compatibility with older code: if foo was a regular procedure in an earlier version of my library, then I added a few optional keyword arguments, I want my dependents’ code which uses foo in all the same ways as a regular Scheme procedure to keep working.

>> Does (a) mean that no keyword arguments can be mandatory?
>
> Yes: mandatory arguments have to be positional.  I think the make-point example shows what's wrong with that.
>
>> And (c) means that all optional arguments (whether positional or named) get the same default, but you get to choose what it is?
>
> No, I meant that the default is always #f as discussed above.

I don't see the need for either restriction on the basis of what I currently know about how existing keyword implementations work. If there were an implementation with this behaviour, we would need to decide between either compromising to not be able to bridge to that Scheme implementation’s native system, or compromising to have the same restriction in the portable system. But all existing implementations I’ve tried so far support specifying your own default/initializer expression for each individual keyword arguments, with identical evaluation semantics; and by extension they all support mandatory keyword arguments — even if only by using (error "missing keyword argument") as the initializer expression.

>> This is indeed a nifty feature, but if the point is interop with existing implementations, I don't think we can do it: Gerbil/SRFI 89 make calling a procedure with unknown keyword arguments an error; in DSSSL-like systems, allow-other-keys appears to be the default, and there's no way to turn it off.
>
> I agree; I just think it should be mentioned in a paragraph of your survey.

Added for the next revision. (Which should be out soon.)

Thank you again,

Daphne