Email list hosting service & mailing list manager

Wrapping up SRFI 177: Portable keyword arguments Lassi Kortela (22 Feb 2020 00:48 UTC)
Comparing current and potential future syntaxes Lassi Kortela (22 Feb 2020 01:25 UTC)
Re: Comparing current and potential future syntaxes John Cowan (22 Feb 2020 22:17 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments John Cowan (22 Feb 2020 21:22 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Lassi Kortela (22 Feb 2020 22:17 UTC)
Hygiene and allow-other-keys Lassi Kortela (22 Feb 2020 22:39 UTC)
Re: Hygiene and allow-other-keys Shiro Kawai (22 Feb 2020 23:48 UTC)
Re: Hygiene and allow-other-keys John Cowan (22 Feb 2020 23:52 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments John Cowan (22 Feb 2020 23:40 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Shiro Kawai (22 Feb 2020 23:58 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Lassi Kortela (23 Feb 2020 00:12 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments John Cowan (23 Feb 2020 01:03 UTC)
Required keyword arguments Lassi Kortela (23 Feb 2020 07:39 UTC)
Re: Required keyword arguments John Cowan (23 Feb 2020 16:35 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (23 Feb 2020 08:33 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Lassi Kortela (23 Feb 2020 10:09 UTC)

Re: Wrapping up SRFI 177: Portable keyword arguments Lassi Kortela 23 Feb 2020 00:12 UTC

> About performance and making it macros--
>
> To argue for macros based on performance is only valid when you want to
> implement such optimization
> portably.  An implementations can always employ inlining
> keyword-argument parsing, therefore process keyword
> argument binding at compile-time, as far as it can prove the procedure
> binding is not altered and all the keyword
> arguments are available at call site literally (such condition is
> _forced_ if lambda/kw creates a macro, but that
> only restricts the use of keyword arguments.)

Good point.

If define/kw were a macro, and there was no lambda/kw at all, then it
would be possible to specify define/kw such that only literal keywords
known at compile time are allowed. So there would be no need to account
for the possibility that keywords need to be parsed at run time. Whereas
in traditional Lisp, parsing them at run time has been the default thing
to do, and parsing at compile time is an optimization.

> So, the question should be if we want a _portable_ optimizing
> implementation or not.  If it's just a possibility
> to allow *some* implementations to do optimization, they can do it
> without forcing it a macro.

IMHO the portable implementation doesn't need to be fast. You have to
have unrealistic numbers of arguments or calls/second for it to really
matter. In that case, it's best to avoid keyword lambdas in the hot path
and use ordinary lambdas. I guess some 3D graphics software uses
complicated argument lists for procedures that need to run fast. But
that's quite fringe. The point of keyword args is to be optional; and
optional args require conditional statements in the procedure body. Why
would we put so many conditional statements into the hot path?