Email list hosting service & mailing list manager

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 (09 Mar 2020 09:16 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 09 Mar 2020 09:16 UTC

> `let-optionals' has the advantage that we do no need any heavy new
> syntax to call and to define procedures taking optional arguments.  It
> also has the advantage that no new concept is needed (namely that of
> keyword arguments).
>
> It is no full replacement for keyword arguments, though.  You can
> meaningfully redo a procedure like `fox' from SRFI 183 with keyword
> arguments but not with optional arguments in the sense of `let-optionals'.

Agreed.

As Amirouche mentioned, there's a similar `let-keywords` in Chibi. IMHO
it has the same problem: it's not part of a standard lambda list
definition, so it's harder for humans and machines to analyze.

> Thus, the answer also depends on whether we want and need to have the
> full power of keyword arguments (and the full potential of abusing them)
> in R7RS-large or whether we think it is possible and sensible to stick
> to the way optional arguments have been handled so far in
> R7RS-small/R7RS-large.

IMHO we should consider the prior art here. People have written large
Lisp systems for decades. If one can be found that avoids keyword args
and is still easy to read, it would make for a good case study.

In Emacs, the parts lifted from (or inspired by) CL use keyword args,
and they are easier to read than the parts using positional optional
args. RMS didn't like keyword arguments so they were kept out for long.

> I haven't understood Lassi's argument about standardization, though.  As
> much as `call/kw' can be standardized, so can `let-optionals'.

Sorry, I was using the word "standard" ambiguously. I mean
standardization in the sense that different programmers would do the
same task the same way, i.e. conventions.

If optional arguments are done via case-lambda or SRFI 89, it's easier
to write tools like a documentation generator or an optimizer since
those tools have a standard place where to look for optional (and
keyword) arguments.

If it's just ordinary Scheme code matching on a lambda-list, the
analysis for tools (and humans) to figure out whether it parses the
procedure's arguments, or something else entirely, becomes harder. Every
time I see a let-optionals or let-keywords, I need to stop and verify
what it's doing. I've never had that feeling in Common Lisp, where
optional and keyword args are always in a natural place in the lambda
list itself. CL also has destructuring-bind (similar to Scheme's `
match`; a superset of let-optionals) for arbitrary lists. You can use it
to parse a rest argument, but people always use the standard optional
and keyword arguments. The convention makes code easy to read and
process. I'd like to have similar conventions for Scheme; hence a
standard case-lambda is a step in the right direction, and a standard
lambda/kw or define/kw (or their superset) could be another.

> Some may
> even say that the advantage of the latter is that it has been in use for
> a long time (for example, the reference implementation of SRFI 1 from
> 1998/99 is already using `let-optionals').

Keyword arguments have been used for decades in Lisp. If they were a new
invention, I'd be more suspicious.