Am Sa., 9. Nov. 2019 um 04:30 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Wed, Nov 6, 2019 at 5:21 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> I have taken a look at your
>> https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/FilesAdvancedCowan.md.
>> I hope this is what you have had in mind.
>
>
> That's out of date, but for the discussion of principles it's just fine.
>
>>
>> The "settings" argument is used for procedures opening files, which
>> are non-trivial themselves. Thus, I don't think the loss of
>> performance when plists are used will be noticeable in any way;
>
>
> In this case I agree, but I'd like a more general solution for times when performance does matter, but we still want readable calls.
>
>>
>> furthermore, an optimizing compiler should be able to compile it
>> efficiently when the called procedure is known at the call site.
>
>
> "Should" is the operative word.  See the C2 Wiki page on "sufficiently smart compiler" at <http://wiki.c2.com/?SufficientlySmartCompiler>.

Thanks for the link!

The same argument has been used for all keyword argument proposals so
far. When the called procedure is not known at compile time, keyword
arguments won't be faster than plists or alists; when the called
procedure is known, they may lead to code as fast as if there are only
positional arguments — given a "sufficiently smart compiler". :)

If we want to guarantee optimization, we have to move everything to
macros and compile-time (which was one of my earlier proposals for
SRFI 177).

>
>>
>> As many procedures share the same settings argument, a better
>> solution, though, seems to be to define an opaque "settings" type.
>
>
> That seems to be about what R6RS does.  I'll take another look at it.

To make this as easily usable as keyword arguments, a new kind of
definition could be standardized:

(define-plist-type <property-type-descriptor>
  make-plist
  plist?
  (prop1 defaul1 getter1 setter1)
  ...)

This would expand into an appropriate record type definition with
predicate "plist?". The identifier "make-plist" would be bound to
syntax taking a plist of a subset of the defined properties and that
expands into an appropriate constructor of the underlying record.

E.g.:

(define-plist-type <file-settings>
  file-settings
  file-settings?
  (bidirectional #f file-settings-bidirectional?)
  (append #f file-settings-append?)
  (encoding 'utf-8 file-settings-encoding)
  ...)

(call-with-input-file <pathname> (file-settings encoding 'latin1
append #t) <proc>)

>> I was referring to the idea that the main advantage of keyword
>> arguments is that parameters can be added to API calls in a
>> backward-compatible way.
>
>
> I think the main advantage is readability.  You can just as well add ordinary unnamed arguments at the end of an ordinary lambda-list, but at a high cost in readability.
>
>>
>> So far, R7RS-large already includes a huge number of procedures. None
>> of these make use of keyword arguments but the solve the perceived
>> problem in other, not less elegant, ways. Confer my example of
>> "set-copy" and "set-filter" in SRFI 113, for example. If R7RS-large
>> had had keyword arguments from the start, only "set-copy" would have
>> been needed.
>
>
> True, but that's linear, not combinatorial.  If you want to copy doing this and then that and then that and then you're done, you need a lazy invocation framework, not keyword options.
>
>>
>> If keyword arguments suddenly go into widespread use in the middle of
>> the standardization process of R7RS-large, we end up with a not very
>> uniform overall API of R7RS-large.
>
>
> IMO, this is the first time we have needed p-lists or keywords or other such things.

I will have to go through the currently standardized API again.

Marc