Reviewing named and optional parameters Daphne Preston-Kendal 07 Jun 2021 15:45 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 07 Jun 2021 16:07 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 09 Jun 2021 08:49 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 09:13 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 09 Jun 2021 09:42 UTC
Re: Reviewing named and optional parameters Marc Feeley 09 Jun 2021 10:24 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 10:32 UTC
Re: Reviewing named and optional parameters Marc Feeley 09 Jun 2021 12:16 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 12:40 UTC
Re: Reviewing named and optional parameters Marc Feeley 09 Jun 2021 13:10 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 15:56 UTC
Re: Reviewing named and optional parameters Marc Feeley 09 Jun 2021 18:15 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 10:27 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 14 Oct 2021 10:42 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 17:22 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 17:37 UTC
Re: Reviewing named and optional parameters Peter Bex 08 Jun 2021 05:17 UTC
Re: Reviewing named and optional parameters Per Bothner 08 Jun 2021 05:38 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 09 Jun 2021 09:00 UTC
Re: Reviewing named and optional parameters Per Bothner 10 Jun 2021 17:23 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 21 Jun 2021 07:23 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 09 Jun 2021 08:55 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 14:29 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 14:44 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 17:03 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 17:33 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 17:37 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 17:40 UTC
Re: Reviewing named and optional parameters John Cowan 09 Jun 2021 19:01 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 09 Jun 2021 19:25 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 10 Jun 2021 10:17 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 10 Jun 2021 11:18 UTC
Re: Reviewing named and optional parameters John Cowan 12 Jun 2021 22:08 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 21 Jun 2021 07:21 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 21 Jun 2021 10:37 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 29 Jul 2021 09:42 UTC
Re: Reviewing named and optional parameters John Cowan 29 Jul 2021 23:34 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 30 Jul 2021 07:03 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 30 Jul 2021 07:31 UTC
Re: Reviewing named and optional parameters John Cowan 30 Jul 2021 21:39 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 30 Jul 2021 21:47 UTC
Re: Reviewing named and optional parameters John Cowan 30 Jul 2021 21:49 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 30 Jul 2021 21:59 UTC
Re: Reviewing named and optional parameters John Cowan 30 Jul 2021 21:32 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 31 Jul 2021 10:02 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 31 Jul 2021 10:29 UTC
Re: Reviewing named and optional parameters John Cowan 31 Jul 2021 17:33 UTC
Re: Reviewing named and optional parameters Daphne Preston-Kendal 31 Jul 2021 17:45 UTC
Re: Reviewing named and optional parameters Marc Nieper-Wißkirchen 31 Jul 2021 18:04 UTC
Re: Reviewing named and optional parameters John Cowan 31 Jul 2021 19:52 UTC

Re: Reviewing named and optional parameters Daphne Preston-Kendal 21 Jun 2021 07:21 UTC

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