From: William H. N. <wil...@ai...> - 2003-06-17 01:07:59
|
(I realize that some stuff related to this has been discussed before, but I'm having trouble reconstructing it.) I'd like to patch the (COMPUTE-EFFECTIVE-METHOD SHORT-METHOD-COMBINATION T) method either with a NO-APPLICABLE-METHOD call or with a comment recording once and for all why it can't be done. When I do (defgeneric foo (x)) (defmethod foo :around ((x integer)) (+ 1 x)) ; never does CALL-NEXT-METHOD (foo 12) in sbcl-0.8.0.72 it fails: "There is no primary method...". Some text in ANSI "7.6.6.2 Standard Method Combination" makes it sound to me as though the FOO call should work: If there are any around methods, the most specific around method is called. It supplies the value or values of the generic function. full stop. All text referring to other methods seems to be phrased more conditionally, e.g. "CALL-NEXT-METHOD can be used to call...", in a way which seems consistent with the possibility that if there are no around methods that's OK as long as C-N-M is never used. For the purposes of error handling in COMPUTE-EFFECTIVE-METHOD (GENERIC-FUNCTION SHORT-METHOD-COMBINATION T) I think it would be convenient if the FOO call would work, since then * if there's an around method we just call it and let it end up in NO-NEXT-METHOD if it tries to call CALL-NEXT-METHOD, and * if there's no around or primary method, we could call NO-APPLICABLE-METHOD, and * that's all she wrote, all errors end up in ANSI-specified hooks NO-APPLICABLE-METHOD or NO-NEXT-METHOD. That seems as though it would be preferable to the sbcl-0.8.0.72 approach of just signalling a SIMPLE-ERROR (not NO-APPLICABLE-METHOD). So is there some reason that * we can't allow the FOO call to work, and/or * we can't use NO-APPLICABLE-METHOD to handle errors in the COMPUTE-EFFECTIVE-METHOD method? -- William Harold Newman <wil...@ai...> Saying that taste is just personal preference is a good way to prevent disputes. The trouble is, it's not true. You feel this when you start to design things. -- <http://www.paulgraham.com/taste.html> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Paul F. D. <di...@dl...> - 2003-06-17 01:26:32
|
William Harold Newman wrote: > (I realize that some stuff related to this has been discussed before, > but I'm having trouble reconstructing it.) > > I'd like to patch the > (COMPUTE-EFFECTIVE-METHOD SHORT-METHOD-COMBINATION T) method either > with a NO-APPLICABLE-METHOD call or with a comment recording once and > for all why it can't be done. > > When I do > (defgeneric foo (x)) > (defmethod foo :around ((x integer)) (+ 1 x)) ; never does CALL-NEXT-METHOD > (foo 12) > in sbcl-0.8.0.72 it fails: "There is no primary method...". Section 7.6.6.2, paragraph 15: "In standard method combination, if there is an applicable method but no applicable primary method, an error is signaled." The standard doesn't dictate what kind of error should be signalled here. Paul |
From: William H. N. <wil...@ai...> - 2003-06-17 02:17:10
|
On Mon, Jun 16, 2003 at 08:33:43PM -0500, Paul F. Dietz wrote: > William Harold Newman wrote: > > >(I realize that some stuff related to this has been discussed before, > >but I'm having trouble reconstructing it.) > > > >I'd like to patch the > >(COMPUTE-EFFECTIVE-METHOD SHORT-METHOD-COMBINATION T) method either > >with a NO-APPLICABLE-METHOD call or with a comment recording once and > >for all why it can't be done. > > > >When I do > > (defgeneric foo (x)) > > (defmethod foo :around ((x integer)) (+ 1 x)) ; never does > > CALL-NEXT-METHOD > > (foo 12) > >in sbcl-0.8.0.72 it fails: "There is no primary method...". > > Section 7.6.6.2, paragraph 15: "In standard method combination, if there > is an applicable method but no applicable primary method, an error is > signaled." OK, it's even in the same section as what I quoted.:-( Now I guess I'll just put the citations to the standard into the comments at the code which I found confusing, and wonder why ANSI did this thing. > The standard doesn't dictate what kind of error should be signalled here. Right. Thank you. -- William Harold Newman <wil...@ai...> Saying that taste is just personal preference is a good way to prevent disputes. The trouble is, it's not true. You feel this when you start to design things. -- <http://www.paulgraham.com/taste.html> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Gerd M. <ger...@t-...> - 2003-06-17 09:29:02
|
William Harold Newman <wil...@ai...> writes: > > >I'd like to patch the > > >(COMPUTE-EFFECTIVE-METHOD SHORT-METHOD-COMBINATION T) method either > > >with a NO-APPLICABLE-METHOD call or with a comment recording once and > > >for all why it can't be done. > > > > > >When I do > > > (defgeneric foo (x)) > > > (defmethod foo :around ((x integer)) (+ 1 x)) ; never does > > > CALL-NEXT-METHOD > > > (foo 12) > > >in sbcl-0.8.0.72 it fails: "There is no primary method...". > > > > Section 7.6.6.2, paragraph 15: "In standard method combination, if there > > is an applicable method but no applicable primary method, an error is > > signaled." > > OK, it's even in the same section as what I quoted.:-( > > Now I guess I'll just put the citations to the standard into the > comments at the code which I found confusing, and wonder why ANSI did > this thing. Just wanted to add one thing... Your example above uses standard method combination, but you also say you'd like to patch a method for SHORT-METHOD-COMBINATION. That method is used for the short form of DEFINE-METHOD-COMBINATION, which includes the standardized method combinations like PROGN, LIST, etc. For these short method combination cases, the description of DEFINE-METHOD-COMBINATION says that an error should be signaled: A method combination procedure defined in this way recognizes two roles for methods. A method whose one qualifier is the symbol naming this type of method combination is defined to be a primary method. At least one primary method must be applicable or an error is signaled. |
From: Christophe R. <cs...@ca...> - 2003-06-17 09:51:10
|
Gerd Moellmann <ger...@t-...> writes: > William Harold Newman <wil...@ai...> writes: >> [Paul Dietz] >> > Section 7.6.6.2, paragraph 15: "In standard method combination, if there >> > is an applicable method but no applicable primary method, an error is >> > signaled." >> >> Now I guess I'll just put the citations to the standard into the >> comments at the code which I found confusing, and wonder why ANSI did >> this thing. > > Just wanted to add one thing... > > Your example above uses standard method combination, but you also say > you'd like to patch a method for SHORT-METHOD-COMBINATION. That > method is used for the short form of DEFINE-METHOD-COMBINATION, which > includes the standardized method combinations like PROGN, LIST, etc. > > For these short method combination cases, the description of > DEFINE-METHOD-COMBINATION says that an error should be signaled: > > A method combination procedure defined in this way recognizes two roles > for methods. A method whose one qualifier is the symbol naming this type > of method combination is defined to be a primary method. At least one > primary method must be applicable or an error is signaled. In keeping with the philosophy that we've been applying a while back, would it be "ideal" (for want of a better word) for this error to be mediated via NO-PRIMARY-METHOD? At present, SBCL isn't exporting NO-PRIMARY-METHOD, but it does seem to have the potential of being a relatively useful extension. Gerd, is it documented/exported in CMUCL? What are your feelings? Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: <ger...@t-...> - 2003-06-17 09:59:31
|
Christophe Rhodes <cs...@ca...> writes: > In keeping with the philosophy that we've been applying a while back, > would it be "ideal" (for want of a better word) for this error to be > mediated via NO-PRIMARY-METHOD? > > At present, SBCL isn't exporting NO-PRIMARY-METHOD, but it does seem > to have the potential of being a relatively useful extension. Gerd, > is it documented/exported in CMUCL? What are your feelings? Incidentally :), I've just patched CMUCL to use NO-PRIMARY-METHOD there; the old error message really was no good. And I've exported NO-PRIMARY-METHOD and NO-PRIMARY-METHOD-ERROR from PCL, and put an item in the release notes for 19a. Probably should also add something to the CMU User Manual... |
From: William H. N. <wil...@ai...> - 2003-06-17 14:51:38
|
On Tue, Jun 17, 2003 at 11:57:24AM +0200, Gerd Moellmann wrote: > Christophe Rhodes <cs...@ca...> writes: > > > In keeping with the philosophy that we've been applying a while back, > > would it be "ideal" (for want of a better word) for this error to be > > mediated via NO-PRIMARY-METHOD? > > > > At present, SBCL isn't exporting NO-PRIMARY-METHOD, but it does seem > > to have the potential of being a relatively useful extension. Gerd, > > is it documented/exported in CMUCL? What are your feelings? > > Incidentally :), I've just patched CMUCL to use NO-PRIMARY-METHOD > there; the old error message really was no good. And I've exported > NO-PRIMARY-METHOD and NO-PRIMARY-METHOD-ERROR from PCL, and put > an item in the release notes for 19a. Probably should also add > something to the CMU User Manual... At the moment my tree has FIXME comments explaining that calling NO-PRIMARY-METHOD seems appropriate in one of the cases there, and NO-APPLICABLE-METHOD seems appropriate in the other case, but that in both cases I don't know how to get to the function arguments cleanly. (Both NO-FOO-METHOD functions want to know the arguments which caused the problem.) Expanding into a reference to the magic symbol .ARGS. could work, but I didn't know whether it's clean enough (e.g. to be MOPpishly reliable). However, I am not surprised that Gerd knows.:-) I don't think I'll have time today, but maybe tomorrow I can reconnect my lightning-traumatized personal workspace to CMU CL CVS, figure out how it's done, and port the fix to SBCL. -- William Harold Newman <wil...@ai...> Saying that taste is just personal preference is a good way to prevent disputes. The trouble is, it's not true. You feel this when you start to design things. -- <http://www.paulgraham.com/taste.html> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |