Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CLISP/Clozure signal error where SBCL runs fine

42 views
Skip to first unread message

giorgos.p...@gmail.com

unread,
Jun 17, 2013, 5:35:12 PM6/17/13
to
I have stumbled upon a peculiar difference of SBCL behavior compared
with Clozure and CLISP. The following code runs fine in SBCL but throws
an error in Clozure and CLISP.

(defgeneric render (obj &rest args))

(defmethod render ((obj t) &key)
(print obj))

(defmethod render ((obj list) &rest args)
(mapc (lambda (item)
(apply #'render item args))
obj))

(defmethod render ((obj number) &key sign)
(print (* sign obj)))

(render (list 1 2 3 4) :sign -1)

SBCL runs normally, but both CLISP and Clozure complain about the :sign
keyword argument. The culprit seems to be the method on T, which
prevents the method on list to run. If I omit the method on T, or I
define it e.g. on built-in-class, the error is gone.

According to my reading of CLHS (7.6.4 & 7.6.5), SBCL correctly accepts
the keyword, so I think there is a bug in Clozure and CLISP. Or maybe
this is some kind of undefined behavior. What do you think?

-- Giorgos

Pascal J. Bourguignon

unread,
Jun 17, 2013, 6:48:20 PM6/17/13
to
Well, it looks indeed like signaling an error here is not conforming to
the letter ofo 7.6.4 (which doesn't exclude a case like yours, and
therefore implementations should allow it).


Of course, your code would be much better if you used &key consistently,
notably in the defgeneric form:

(defgeneric render (obj &key &allow-other-keys))


But otherwise, I'd agree that implementations should not signal an error
here.


--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
You know you've been lisping too long when you see a recent picture of George
Lucas and think "Wait, I thought John McCarthy was dead!" -- Dalek_Baldwin
0 new messages