Email list hosting service & mailing list manager

Re: R7RS-large backward compatibility John Cowan (08 Mar 2020 21:58 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: R7RS-large backward compatibility Lassi Kortela 08 Mar 2020 22:40 UTC

> Comments and corrections?

That was an excellent summary of the issues. Thank you for your patience
in dealing with the rest of us who struggle to grasp the full extent of
the issues.

If _requiring_ new syntax is off-limits, _and_ keyword arguments are
added in, then R7RS-large needs a macro-based approach like SRFI 177.
Those constraints simplify our job.

A good argument for standard keyword arguments is that, empirically,
Scheme programmers keep hacking around the problem quite a bit.
Rest-list parsing is not uncommon, and that code is significantly less
elegant and optimized than it would be just to use something like
lambda/kw, even in its current form in SRFI 177 draft 2. My argument is
that it's hard to do worse than the current situation in the wild, and
from that point of view standardization is not that risky.

I guess it is possible to paint yourself into a corner in the standard
by specifying a really fancy keyword system where some design decisions
later turn out to be mistakes. As far as I can tell, worries of that
kind can be avoided by specifying a less ambitious keyword system that
leaves more options open. The bare basics (current SRFI 177 semantics)
adequately cover probably >95% of real use cases.

Since there is an interesting debate going on about hygiene, the current
syntax-rules-compatible (call/kw 1 2 (c 3 d 4)) syntax would give
flexibility there. Something like (call 1 2 &key c 3 d 4) has also been
suggested.