Am Di., 3. März 2020 um 09:57 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>         The difference is not subtle at all: macros resemble procedures
>         only in the general appearance of an invocation.  Lambda defines
>         a procedure, and even though there is no kw-apply, you can still
>         retrofit keywords to procedures and apply those procedures to
>         regular positional arguments without breaking them.
>
>     I agree with you that we would give up the ability of retrofitting
>     and that this would make keyword arguments much less useful.
>
> Having thought about this once more, I have to retract this point. With
> identifier syntax, it is very well possible to retrofit procedures with
> keyword arguments. A procedure with keyword arguments, even if it
> implemented as syntax, can still evaluate to an ordinary procedure when
> not used as a macro keyword.

This would require adding identifier syntax to R7RS-large, as you noted.

Unless I have misunderstood something, identifier syntax is basically
the same as symbol macros in Common Lisp. I Liked having them, but they
always seemed like there could be weird edge cases that blow up
unexpectedly. I never encountered any concrete problems with it, but
always felt like it shouldn't work that easily :)

I think there have been some misconceptions about identifier syntax. We should discuss this when we discuss the low-level macro systems. In any case, identifier syntax has very compelling use cases; the above idea is one of them.


One important use I'd like to preserve with kw args is higher-order
functions. With the current 177 you can make a lambda/kw and pass it to
another procedure that can call it using any of these:

- (foo args...)
- (apply foo args...)
- (call/kw foo args... (kws...))

That makes things really simple for users. I don't see a way to preserve
all of these possibilities without identifier syntax. Since 177 needs to
be usable immediately, it can't rely on new kinds of macros. That means
177 should probably specify lambda/kw to return real lambdas.

Now we have returned to the argument that, from a technical point of view, we seem to be specifying things in the wrong order. SRFI 177 is shaped by what is possible today. When SRFI 177 gets voted into R7RS-large, by the end of the day, it should be shaped by what is possible in R7RS-large. :(


However, call/kw could be extended so it's allowed to call things that
are not real lambdas. Since call/kw is a macro that just expands to (foo
...), anything that is a valid procedure or macro call in the underlying
Scheme implementation should in principle work? I just thought of this
idea for the first time and may not understand all the details.

Chez Scheme has compile-time properties: https://cisco.github.io/ChezScheme/csug9.5/syntax.html#./syntax:h4. If we get a similar thing into R7RS-large, a macro could decide on the nature of the second argument.

Again, it would be nice if could discuss and agree upon general runtime semantics first, then reader syntax, then the syntactic system, then keyword objects and then the applications.
Marc