Hey,

You seem to be asking for opinions. I do think adding keyword args is fine. I believe Franz does this, and it works well.

This is certainly an established practice - another example is make-hash-table (and weakness arguments). That said it is annoying to quote two arguments, i.e (make-hash-table #+ICL :weakness #+ICL :key #+OPK :key-weakness #+OPK t) Best regards, Daniel -- Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland TurtleWare - Daniel Kochmański      | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi

-------- Date: Tue, 24 Jan 2023 12:23:36 +0000 From: =?utf-8?Q?Daniel_Kochma=C5=84ski?= <daniel@turtleware.eu> Hey, > You seem to be asking for opinions. I do think adding keyword > args is fine. I believe Franz does this, and it works well. > This is certainly an established practice - another example is > make-hash-table (and weakness arguments). That said it is > annoying to quote two arguments, i.e (make-hash-table #+ICL :weakness #+ICL :key #+OPK :key-weakness #+OPK t) It is indeed annoying, and the #+allegro additions to this code might include either `:values :weak' or `:weak-keys t'. The use of any of these extensions, however, makes the program non-portable, as is also documented in the spec. I do like Pascal's solution later in this thread. which brings programs using these extensions back into the category of "portable". Make-hash-table is a good example of extensions being a Good Thing. For our next version we've added an :implementation keyword, which allows you to roll your own hash-table implementation using excl:def-hash-table-implementation (and then naming it in the make-hash-table call). The thing about hash-table extensions is that they are _fun_! Another aspect of extensions is the ability to extend existing keywords. This is also demonstrated in Allegro CL by the :test keyword, which is specified to have values that are designators for cl:eq, cl:eql, cl:equal, and cl:equalp. But our extension allows you to specify any test you want, which of course thus requires yet another make-hash-table keyword :hash-function (which the user specifies to generate their own hash code). I agree with most of the comments in this thread. As an implementor, I would say that without the ability to extend keywords, we would be severely limited in what we could offer you. It comes, of course, with a level of responsibility for the user to keep their programs as portable as possible, but of course if you want to stick with one implementation it really doesn't matter. But that's the main goal of the spec, when it comes down to it. Best regards, Daniel -- Daniel Kochma=C5=84ski ;; aka jackdaniel | Przemy=C5=9Bl, Poland TurtleWare - Daniel Kochma=C5=84ski=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | www.tur = tleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi --------

Raymond Wiker <rwiker@gmail.com> wrote:

If you check the HyperSpec entry for “trace”, you’ll see that it accepts implementation-specific additional arguments. I’m pretty sure I’ve seen other examples, but I cannot remember what they were just now.

This is one of the cases where extensions are /explicitly/ authorized. Another one is DEFGENERIC. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

Martin Simmons wrote:

I think it does, because section 3.5.1.4 Unrecognized Keyword Arguments says that an error must be signaled for unrecognized keywords in a safe call, so that will not happen for an extension keyword.

I'm not sure I understand this. Do you mean that safety declarations don't apply to extensions ? On the other hand, this section says: "It is not permitted to supply a keyword argument to a function using a name that is not recognized by that function [...]", but my reading of it is that if an extension provides an additional keyword argument, then the function actually "recognizes" it, so it seems to me that this section should not apply at all. -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

-------- Date: Wed, 25 Jan 2023 16:00:58 +0100 From: Didier Verna <didier@didierverna.net> Martin Simmons wrote: > I think it does, because section 3.5.1.4 Unrecognized Keyword > Arguments says that an error must be signaled for unrecognized > keywords in a safe call, so that will not happen for an extension > keyword. I'm not sure I understand this. Do you mean that safety declarations don't apply to extensions ? No. Note that 3.5.1.1 is under 3.5.1, which is "Argument Mismatch Detection". This applies to _all_functions defined, not just standard functions. So if I create a function foo with keywords bar and bas, the only way you can call foo with a :baz keyword withouit getting an error is by also including :allow-other-keys t (or if the function was originally defined with &allow-other-keys t). That applies not only to standard functions, but to user-defined functions as well. If in my example case, I call foo as (foo :baz t) in safe code I get an error, as the spec requires. On the other hand, this section says: "It is not permitted to supply a keyword argument to a function using a name that is not recognized by that function [...]", but my reading of it is that if an extension provides an additional keyword argument, then the function actually "recognizes" it, so it seems to me that this section should not apply at all. Yes, as it is really applying to _all_ functions defined with keywords. Most CL implementations provide a function that provides you with the argument list of a function (in Allegro CL it is #'excl:arglist). With such a function. most of the time (unless arglist info is stripped from the lisp or from that function) you can see the argument list of the function in question and it may include &key in the list, which will thus tell you what keywords you can use in a conforming manner. --=20 Resistance is futile. You will be jazzimilated. Lisp, Jazz, A=C3=AFkido: http://www.didierverna.info --------