On 9 Jun 2021, at 16:29, John Cowan <xxxxxx@ccil.org> wrote:

> Various comments:
>
> 1) If you have Docker installed, you can run schemers/stklos and many other implementations (but not s7 at present; ask Lassi to build it if you want it).

Thanks for the info. I'm not very good with Docker but I'll take a look.

> 2) s/Something which is referred to as being 'portable' means'/A 'portable implementation' is one which/

Corrected for the next revision.

> 3) Add this definition:  "A 'bridged implementation' is a set of non-portable implementations of the same API.  If there are enough implementations in the set, it may be treated as portable to existing implementations of Scheme although not necessarily to new ones."  I think we will need it later, and such a term has been lacking for a long time (but if you have a better term, by all means use it).

This is a handy term; I think I could make use of it in the document already. I’ll have another look through.

> 4) Portability to R6RS should also be treated as relevant, I think.

Agreed. I mention Chez in a few places, but not the R6RS standard. Part of the problem there is that I have very little experience working with R6RS. Are there any pressing differences that mean a system that would work in R7 small would not also automatically be portable to R6, other than the peripheral ones affecting essentially all code (e.g. the different library definition syntax)?

> 5) Symbols with just colons are valid R7RS-small, but have weird results in native-keyword systems.  `:` for example may have a name of "" or of ":".  So while (: foo) looks very nice, it will not work in Chicken, e.g.

It works for me in Chicken 5.2.0. I notice that your survey found that Gauche, Sagittarius, and STklos treat it as a keyword. In Gauche it works anyway by default because keywords are symbols, but it explodes when GAUCHE_KEYWORD_DISJOINT is on, and in Sagittarius.

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. However, as the point is compatibility, it seems I’ll have to think of another name, sigh.

> 6) In my view a keyword-friendly version of `define` (rather than `lambda`) should be primitive, as I don't see much use in having an anonymous function that can accept keywords.

I think from one practical standpoint you're correct — in particular, if syntax-case and identifier syntax *is* used to get an optimized implementation, afaik only the `define-keyword` form could take advantage of that. 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, so they’d have to implement `lambda-keyword` anyway, so I see no harm in providing it and considering it the fundamental constructor. However, I will note in the next revision that using `define-keyword` may yield more performant procedures than `lambda-keyword`.

> 7) By the same token, all this about having optional and keyword arguments in the same procedure strikes me as unnecessary, not to mention problematic in CL-style systems, where if you have left out an even number of optional arguments, one of your keyword arguments just vanishes.  Better to forbid it by construction, I think, so optional arguments *or* keyword arguments, says I.

I don’t understand how your point here differs from my conclusion in the relevant section: ‘The syntax forms to define procedures with optional positional arguments and to define procedures with keyword arguments are completely distinct. There is no way, in the standard keyword argument system, to have a procedure which takes optional positional arguments; a procedure which takes any keyword arguments must use them for all its optional arguments, if any. This does not preclude the possibility of implementation-specific or user-defined syntax for procedures which can receive both kinds of arguments.’

Could you explain more, if you're trying to make a different point?

> 8) There are cases where default keyword or optional values can't be reduced to a non-arbitrary value.  For example, a function to construct a graph node might have a keyword argument :parent, but if omitted it would mean that there was no parent.  This could be conventionally handled with a :parent value of #f, of course.

Yes. Or if using #f is a problem (e.g., if that might be a real value), a specific magic value with a unique identity (in the sense of `eq?`). But I think those cases are better handled in explicit code.

> 9) I think there are three possibilities for defaults: (a) every optional or keyword argument must have a default, or (b) there is a default default like #f if no specific default is given, or (c) no specific default can be given, and a particular value is always the default.  Of these, (a) and (c) seem more Schemey to me than (b), to which my instinctive reaction is  "ugh, typical CL over-engineering" :-).  In Python I always use None as the default and have code to replace that with what I actually want.  (This also bypasses the bug in Python that you mention.)

There are a few things I don't understand here. Does (a) mean that no keyword arguments can be mandatory? And (c) means that all optional arguments (whether positional or named) get the same default, but you get to choose what it is? Both restrictions seem unnecessary on the basis of my investigation of the features of keyword systems up to now.

> 10) s/are given as a 2-list/are given as 2-lists/

Corrected for the next revision.

> 11) CL has a lambda-list-keyword &allow-other-keys, which means that keys can appear in a call that aren't in the definition.  Since all keywords and values are also in the &rest list, it's possible to apply some other function to the rest list and have that function interpret them.  This leads to a pattern in which you can pass keywords to a function that are not known to it but are known to the function it calls.
>
> The ordinary keyword :allow-other-keys can be used in any function call as well, and if its value is true, allows keys to appear in this particular call that are not in the definition.  This allows a function to follow the above pattern even when invoking functions that weren't defined using &allow-other-keys.

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.

But, as with having both optional position *and* keyword arguments, nothing about a proposed standard definition form prevents people from making their own forms with these features, even if it does mean runtime overhead. Perhaps it *would* be handy to provide utility procedures and macros (like Chibi’s let-keywords) to help out there, even if they are explicitly slower than a definition with define-keyword/lambda-keyword.

> I'll talk in another post about the possibilities of providing a bridging implementation of define/keywords that creates a macro rather than a procedure.

I look forward to it.

Thank you for the feedback!

> John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
> Even the best of friends cannot attend each others' funeral.
>         --Kehlog Albran, The Profit

Daphne Preston-Kendal