On Jun 9, 2021, at 6:32 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>
>
> Am Mi., 9. Juni 2021 um 12:25 Uhr schrieb Marc Feeley - feeley at iro.umontreal.ca (via srfi-discuss list) <xxxxxx@srfi.schemers.org>:
> > On Jun 9, 2021, at 5:42 AM, Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
> >
> >>
> >> If we get rich enough syntactic abstractions, I already wondered (in the context of SRFI 177) whether there is really a need for first-class procedures that take keyword arguments or whether they should all become special forms (with absolutely no runtime overhead). After all, an unknown procedure (a procedure passed around as a first-class value) would very seldom be called with keyword arguments.
> >
> > I considered the possibility of making everything a macro, but I decided losing first-class status of procedures was too high a price to pay, on principle if nothing else. True, it's unlikely (though not impossible) that an arbitrary higher-order procedure (as in map, fold and their respective first arguments) will use keyword arguments, but I can imagine not-so-contrived situations where it would still be useful to pass them around.
>
> I too can imagine situations where having keyword arguments only on macros would be restrictive:
>
> 1) In an object oriented programming style where you call a virtual method through generic call.  The generic call site specifies keyword arguments and there is a dispatch to the actual procedure that does the work that consumes the keyword arguments.
>
> The actual procedure can be implemented as a procedure just taking positional arguments. Some nice syntactic abstraction can help to map keyword arguments to positional arguments. I think this would at least also solve point 2) below. I cannot say much about 3) because there is no generally agreed FFI for Scheme and, further, the semantics of keyword arguments in the FFI targets may not be the same or be compatible.
>
> 2) In higher order procedures whose procedure parameter accepts keyword arguments.  Syntax isn’t a first-class object that can be passed around.
>
> 3) In a FFI between Scheme and a foreign language that supports keyword arguments (Python, Ruby, Common Lisp, Ada, C#, Fortran, R, PHP,  Scala, Smalltalk, etc).

The situations I’m describing can be caracterized as only knowing at run time which set of keyword arguments are allowed and what they mean.  Handling keyword arguments fully at compile time (through macros or some form of compile-time type checking) is thus not general enough.

Much of the discussion on keyword argument handling boils down to a debate between static vs dynamic, which I think is a debate between convenience/dynamic-checking and performance/static-checking.  Some lean more on one side than the other, but both sides have a point.  My preference is more on convenience, because I expect keyword arguments to be used sparingly in general and when they are used it is not in performance critical parts of a program (in the performance critical parts the simpler required, and possibly optional, positional parameters can be used exclusively).

Marc