From: Tobias C R. <tc...@fr...> - 2010-09-05 07:38:59
|
What is SBCL's take on extending the set of &KEY, or &OPTIONAL parameters of a standardized function? CLHS 1.6 allows implementation-dependent extensions, and does NOT disallow extending the set of &key parameter explicitly. CLHS 1.5.2 says, ``Conforming code shall use only those features of the language syntax and semantics that are either specified in this standard or defined using the extension mechanisms specified in the standard.'' So far so good. However: CLHS 3.5.1.4 says, `` It is not permitted to supply a keyword argument to a function using a name that is not recognized by that function'', and even further, ``If this situation occurs in a safe call, an error of type program-error must be signaled;'' Now, I think of 3.5.1.4 as to specify behavior in case of a unrecognized keyword parameter -- that and only that -- in particular, it does not constrain the set of &key parameters of standardized functions to begin with. Is there an official take on this issue? Background is https://bugs.launchpad.net/sbcl/+bug/630680 which in my opinion should be solved by adding an :AUTO-CLOSE parameter to OPEN which defaults to a special variable which defaults to NIL. -T. |
From: Paul K. <pk...@gm...> - 2010-09-05 12:49:06
|
On 2010-09-05, at 3:38 AM, Tobias C Rittweiler wrote: > What is SBCL's take on extending the set of &KEY, or > &OPTIONAL parameters of a standardized function? > [...] > > Background is https://bugs.launchpad.net/sbcl/+bug/630680 > which in my opinion should be solved by adding an > :AUTO-CLOSE parameter to OPEN which defaults to a special > variable which defaults to NIL. How about sb-ext:auto-close as the keyword, instead? That makes the non-standard extension obvious. For convenience, I suppose we'll want to make the symbol a self-evaluating constant. Paul Khuong |
From: <pj...@in...> - 2010-09-05 13:09:46
|
Tobias C Rittweiler <tc...@fr...> writes: > What is SBCL's take on extending the set of &KEY, or > &OPTIONAL parameters of a standardized function? > > > CLHS 1.6 allows implementation-dependent extensions, and > does NOT disallow extending the set of &key parameter > explicitly. > > CLHS 1.5.2 says, ``Conforming code shall use only those > features of the language syntax and semantics that are either > specified in this standard or defined using the extension > mechanisms specified in the standard.'' > > > So far so good. > > However: > > > CLHS 3.5.1.4 says, `` It is not permitted to supply a keyword > argument to a function using a name that is not recognized > by that function'', and even further, ``If this situation occurs > in a safe call, an error of type program-error must be signaled;'' > > > Now, I think of 3.5.1.4 as to specify behavior in case of > a unrecognized keyword parameter -- that and only that -- in > particular, it does not constrain the set of &key parameters > of standardized functions to begin with. 1.6 and 1.5.2 talk about what is specified, while 3.5.1.4 talks about what is implemented. An implementation can specify more keyword arguments (possibly an infinite number of them). But once they're specified, the implementation must check their validity (unless the arguments contain :ALLOW-OTHER-KEYS T). So, IMO, unless it is specified by the implementation that a give function takes any keyword parameter, it must still signal a program-error if passed an unexpected keyword without :ALLOW-OTHER-KEYS T. > Is there an official take on this issue? > > > Background is https://bugs.launchpad.net/sbcl/+bug/630680 > which in my opinion should be solved by adding an > :AUTO-CLOSE parameter to OPEN which defaults to a special > variable which defaults to NIL. > > -T. -- __Pascal Bourguignon__ http://www.informatimago.com/ |