From: Douglas K. <do...@go...> - 2013-10-13 16:41:48
|
The as-always-non-authoritative CLHS says that the function-form to M-V-CALL is a "function designator", not an "extended function designator". So given this: * (defun (setf foo) (a b c) (format t "Hi ~S ~S ~S~%" a b c) a) * (defun bar () (multiple-value-call '(setf foo) (values 1 2) 3)) on the 3 implementations I tried, CCL rejects that and CLISP and SBCL accept. Would anyone care to opine whether that is a CCL bug, a non-CCL bug, an oversight in CLHS...? |
From: Stas B. <sta...@gm...> - 2013-10-13 17:19:17
|
Douglas Katzman <do...@go...> writes: > The as-always-non-authoritative CLHS says that the function-form to > M-V-CALL is a "function designator", not an "extended function designator". > So given this: > > * (defun (setf foo) (a b c) (format t "Hi ~S ~S ~S~%" a b c) a) > * (defun bar () (multiple-value-call '(setf foo) (values 1 2) 3)) > > on the 3 implementations I tried, CCL rejects that and CLISP and SBCL > accept. > Would anyone care to opine whether that is a CCL bug, a non-CCL bug, an > oversight in CLHS...? CLHS is always authoritative (unless it's a clear typo/mistake), since there's nothing else. And it makes sense to require this for efficiency reasons, having to deal only with symbols means funcall can just access symbol's function slot, which cannot be done with lists. (It's not applicable to SBCL, since it currently stores such information in the infodb). So, it's a bug in SBCL, not CLHS. -- With best regards, Stas. |
From: Pascal C. <pc...@p-...> - 2013-10-13 18:32:07
|
> On 13 Oct 2013, at 19:19, Stas Boukarev <sta...@gm...> wrote: > > Douglas Katzman <do...@go...> writes: > >> The as-always-non-authoritative CLHS says that the function-form to >> M-V-CALL is a "function designator", not an "extended function designator". >> So given this: >> >> * (defun (setf foo) (a b c) (format t "Hi ~S ~S ~S~%" a b c) a) >> * (defun bar () (multiple-value-call '(setf foo) (values 1 2) 3)) >> >> on the 3 implementations I tried, CCL rejects that and CLISP and SBCL >> accept. >> Would anyone care to opine whether that is a CCL bug, a non-CCL bug, an >> oversight in CLHS...? > CLHS is always authoritative (unless it's a clear typo/mistake), since > there's nothing else. And it makes sense to require this for efficiency > reasons, having to deal only with symbols means funcall can just access > symbol's function slot, which cannot be done with lists. (It's not > applicable to SBCL, since it currently stores such information in the > infodb). > > So, it's a bug in SBCL, not CLHS This is a very strict reading of the CLHS, which is not entirely justified. You could argue that cases like this fall under section 1.6 of the HyperSpec... Pascal |
From: Stas B. <sta...@gm...> - 2013-10-13 18:27:49
|
Pascal Costanza <pc...@p-...> writes: >> On 13 Oct 2013, at 19:19, Stas Boukarev <sta...@gm...> wrote: >> >> Douglas Katzman <do...@go...> writes: >> >>> The as-always-non-authoritative CLHS says that the function-form to >>> M-V-CALL is a "function designator", not an "extended function designator". >>> So given this: >>> >>> * (defun (setf foo) (a b c) (format t "Hi ~S ~S ~S~%" a b c) a) >>> * (defun bar () (multiple-value-call '(setf foo) (values 1 2) 3)) >>> >>> on the 3 implementations I tried, CCL rejects that and CLISP and SBCL >>> accept. >>> Would anyone care to opine whether that is a CCL bug, a non-CCL bug, an >>> oversight in CLHS...? >> CLHS is always authoritative (unless it's a clear typo/mistake), since >> there's nothing else. And it makes sense to require this for efficiency >> reasons, having to deal only with symbols means funcall can just access >> symbol's function slot, which cannot be done with lists. (It's not >> applicable to SBCL, since it currently stores such information in the >> infodb). >> >> So, it's a bug in SBCL, not CLHS > > This is a very strict reading of the CLHS, which is not entirely > justified. You could argue that cases like this fall under section 1.6 > of the HyperSpec... SBCL shouldn't extend the language in such a way, thus making non-conforming programs to be accepted by SBCL, but failing on other implementations, especially when there's no intention to rely on such behaviour, when the nonconforming form is used unknowingly or by mistake. And it's not strict at all, the definition is of function designators is quite clear and unambiguous. -- With best regards, Stas. |
From: Christophe R. <cs...@ca...> - 2013-10-13 18:58:45
|
Stas Boukarev <sta...@gm...> writes: > So, it's a bug in SBCL, not CLHS. I think describing it as a bug in SBCL is too strong. Programs which exploit this, probably by doing (multiple-value-call funvar ...) where funvar can evaluate to an extended function designator, are non-portable, and indeed do not work in either the compiler or the sexp evaluator, as far as I can tell. What does work is the trivial (multiple-value-call '(setf foo) ...) where I say "trivial" because it can trivially be converted into a conforming program by adding one # character. I wouldn't have any objection to forbidding the explicit list version. But nor would I have an objection to preserving it, while adding a STYLE-WARNING when it happens. Cheers, Christophe |