Hello,
Section 1.6 Language Extensions of the standard says this:
A language extension is any documented implementation-defined behavior of a defined name in this standard that varies from the behavior described in this standard [...]
It is unclear to me if the term "behavior" could encompass additional keyword arguments passed to a function or macro. I'm assuming here that the rest of this section is honored (the additional arguments wouldn't alter the confirming code, and their presence is not explicitly prohibited).
WDYT?
You seem to be asking for opinions. I do think adding keyword args is fine. I believe Franz does this, and it works well.
-Jason
On 24 Jan 2023, at 10:47, Didier Verna didier@didierverna.net wrote:
Hello,
Section 1.6 Language Extensions of the standard says this:
A language extension is any documented implementation-defined behavior of a defined name in this standard that varies from the behavior described in this standard [...]
It is unclear to me if the term "behavior" could encompass additional keyword arguments passed to a function or macro. I'm assuming here that the rest of this section is honored (the additional arguments wouldn't alter the confirming code, and their presence is not explicitly prohibited).
WDYT?
-- Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
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
Le 24/01/2023 à 13:23, Daniel Kochmański a écrit :
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)
You may use:
(make-hash-table :weakness :key :key-weakness t :allow-other-keys t)
but there's the possibility two implementation have the same keyword argument with different values. (then you can use #+/#- just for the values).
-------- 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
--------
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.
On 24 Jan 2023, at 10:47, Didier Verna didier@didierverna.net wrote:
Hello,
Section 1.6 Language Extensions of the standard says this:
A language extension is any documented implementation-defined behavior of a defined name in this standard that varies from the behavior described in this standard [...]
It is unclear to me if the term "behavior" could encompass additional keyword arguments passed to a function or macro. I'm assuming here that the rest of this section is honored (the additional arguments wouldn't alter the confirming code, and their presence is not explicitly prohibited).
WDYT?
-- Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
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.
On Tue, 24 Jan 2023 10:47:49 +0100, Didier Verna said:
Section 1.6 Language Extensions of the standard says this:
A language extension is any documented implementation-defined behavior of a defined name in this standard that varies from the behavior described in this standard [...]
It is unclear to me if the term "behavior" could encompass additional keyword arguments passed to a function or macro.
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.
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.
On Wed, 25 Jan 2023 16:00:58 +0100, Didier Verna said:
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.
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.
I mean that, in general, users can expect the "behavior" of calling a standard function with a non-standard keyword in safe code to be "it signals an error".
If it does something else, then that has changed "the behavior described in this standard" (1.6) and so that should only happen as part of a language extension.
That's why I think the answer to your original question <<if the term "behavior" could encompass additional keyword arguments passed to a function or macro>> is yes.
-------- 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 --------
-
Daniel Kochmański -
Didier Verna -
Duane Rettig -
Jason Cornez -
Martin Simmons -
Pascal Bourguignon -
Raymond Wiker