Re: Wrapping up SRFI 177: Portable keyword arguments John Cowan (02 Mar 2020 23:53 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Feeley (03 Mar 2020 04:46 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 06:29 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 06:43 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 07:51 UTC)
Identifier syntax, and using macros with call/kw Lassi Kortela (03 Mar 2020 08:57 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 09:00 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:06 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 09:19 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:48 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 10:03 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 10:12 UTC)
Re: Identifier syntax, and using macros with call/kw John Cowan (06 Oct 2020 20:20 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (07 Oct 2020 07:29 UTC)
Syntax for identifier syntax Lassi Kortela (03 Mar 2020 09:55 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (03 Mar 2020 10:16 UTC)
Re: Syntax for identifier syntax John Cowan (03 Mar 2020 13:37 UTC)
Re: Syntax for identifier syntax Lassi Kortela (03 Mar 2020 13:42 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (03 Mar 2020 14:59 UTC)
Re: Syntax for identifier syntax Jim Rees (04 Mar 2020 18:12 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (04 Mar 2020 18:18 UTC)
Re: Syntax for identifier syntax John Cowan (04 Mar 2020 23:48 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:13 UTC)
R7RS-large backward compatibility Lassi Kortela (03 Mar 2020 10:31 UTC)
Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (03 Mar 2020 11:31 UTC)
Specifying a meeting point for different keyword systems Lassi Kortela (03 Mar 2020 11:56 UTC)
Re: Specifying a meeting point for different keyword systems Marc Nieper-Wißkirchen (03 Mar 2020 15:03 UTC)
Re: R7RS-large backward compatibility John Cowan (05 Mar 2020 19:36 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (05 Mar 2020 19:51 UTC)
Re: R7RS-large backward compatibility John Cowan (05 Mar 2020 20:03 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (05 Mar 2020 20:17 UTC)
Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (08 Mar 2020 09:00 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (08 Mar 2020 09:06 UTC)
Re: R7RS-large backward compatibility John Cowan (08 Mar 2020 21:58 UTC)
Re: A case for let-optionals and let-keywords (Was: Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility) Lassi Kortela (08 Mar 2020 22:56 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (08 Mar 2020 22:40 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 07:42 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 11:46 UTC)
Re: [scheme-reports-wg2] R7RS-large backward compatibility Lassi Kortela (09 Mar 2020 12:07 UTC)
Re: R7RS-large backward compatibility Per Bothner (09 Mar 2020 16:30 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 16:48 UTC)

Re: A case for let-optionals and let-keywords (Was: Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility) Lassi Kortela 08 Mar 2020 22:55 UTC

> The syntax of SRFI-177 is too heavy, and it requires to learn new
> things in scheme.
>
> So far the arguments in favor of keywords like SRFI-177 are:
>
> - Performance
> - Programming in the large
> - Scripting
>
> In scripting, performance does not really matter. In programming in
> the large, companies can invest in better compilers.

I agree that performance is not a significant problem. It's nice if
calls can be really fast, but I still haven't seen a case where keyword
arguments are needed in the fast path of performance-sensitive code
(graphics, etc.) They tend to be the most useful at the exported API of
a module, called more rarely than the internal procedures.

> That is case of for let-optionals and let-keywords (or similar
> approach relying on rest arguments). This does not introduce a new
> syntax, it is a good uses case for macros, it is portable, it does not
> introduce new things to implement in scheme standard and the syntax is
> clean.
>
> What precludes those macros as keywords facility and as the way-to-go
> for R7RS libraries?

I think I understand your argument, but I have the opposite point of
view: it's macros like `let-keywords` that indicate a problem. It's
similar to exception handling or object systems - while it's true that
everyone can write their own system, that makes it difficult to write
standard tools, and it means different codebases end up doing the same
thing slightly differently. One of my favorite things about Scheme is
how similar code looks in different codebases.

In the case of keyword arguments, as one example documentation
generators are easier to write if there's a standard way to do keyword
arguments (and optional positional arguments - that's currently done
with case-lambda). Compiler optimizations also become possible.

SRFI 177 is approximately as portable as let-keywords; that was the big
win and surprise about it. You're right that let-keywords doesn't need
to be customized for each Scheme implementation, but we're talking about
a very modest amount of code even with separate implementations.