best practices on type safety of/for generic functions

[John Morrison]

Hi All;

This is probably a dumb question, but here goes.

John Alan McDonald (Hi, John, if you're on this list!) has graciously
consented to let me try to revive some almost 20 year old CL software (
Arizona <http://home.comcast.net/~johnamcdonald/jamcdonald0/az93.pdf>).
SBCL doesn't seem to like type-related declarations in defgeneric forms
(per the spec<http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defgeneric.html#defgeneric>).
And there are a lot of defgenerics of the form:

(declaim (declaration :returns)) ;; OK, only once, but then used
repeatedly...

(defgeneric interactor-role-cursor (interactor role)
(declare (type Interactor interactor)
(type (or Interactor-Role Null) role)
(:returns (type xlib:Cursor)))
(:documentation
"Returns the cursor to be used when this Role is current."))

(defmethod interactor-role-cursor ((interactor Interactor)
(role Interactor-Role))
"The default cursor"
(xlt:window-cursor (interactor-window interactor) :target))

I did certainly benefit from some of the runtime errors generated as a
result of the type declarations of some of the defmethods and defuns in my
efforts to update the clx parts of the software.

What is best practice, then, as regards trying to provide useful
type-related information associated with generic functions? Or have I been
so brain-damaged by C++/Java/etc that I am thinking about the problem-space
entirely the wrong way, and thus my solution-space question is entirely
meaningless?

Thanks,

-jm

[Stas Boukarev]

Content preview: John Morrison writes: > Hi All; > > This is probably a dumb
question, but here goes. > > John Alan McDonald (Hi, John, if you're on this
list!) has graciously > consented to let me try to revive some almost 20
year old CL software ( > Arizona <http://home.comcast.net/~johnamcdonald/jamcdonald0/az93.pdf>).

Post by John Morrison
SBCL doesn't seem to like type-related declarations in defgeneric forms
(per the spec<http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defgeneric.html#defgeneric>).
And there are a lot of defgenerics of the form: > > (declaim (declaration

:returns)) ;; OK, only once, but then used > repeatedly... > > (defgeneric
interactor-role-cursor (interactor role) > (declare (type Interactor interactor)

Post by John Morrison
(type (or Interactor-Role Null) role) > (:returns (type xlib:Cursor)))
(:documentation > "Returns the cursor to be used when this Role is current."))

(defmethod interactor-role-cursor ((interactor Interactor) > (role Interactor-Role))

"The default cursor" > (xlt:window-cursor (interactor-window interactor)

:target)) > > I did certainly benefit from some of the runtime errors generated
as a > result of the type declarations of some of the defmethods and defuns
in my > efforts to update the clx parts of the software. > > What is best
practice, then, as regards trying to provide useful > type-related information
associated with generic functions? Or have I been > so brain-damaged by C++/Java/etc
that I am thinking about the problem-space > entirely the wrong way, and
thus my solution-space question is entirely > meaningless? The portable equivalent
would be (declaim (ftype (function (interactor (or interactor-role null))
xlib:cursor) interactor-role-cursor)) [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.215.46 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(stassats[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/762>

Post by John Morrison
Hi All;
This is probably a dumb question, but here goes.
John Alan McDonald (Hi, John, if you're on this list!) has graciously
consented to let me try to revive some almost 20 year old CL software (
Arizona <http://home.comcast.net/~johnamcdonald/jamcdonald0/az93.pdf>).
SBCL doesn't seem to like type-related declarations in defgeneric forms
(per the spec<http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_defgeneric.html#defgeneric>).
(declaim (declaration :returns)) ;; OK, only once, but then used
repeatedly...
(defgeneric interactor-role-cursor (interactor role)
(declare (type Interactor interactor)
(type (or Interactor-Role Null) role)
(:returns (type xlib:Cursor)))
(:documentation
"Returns the cursor to be used when this Role is current."))
(defmethod interactor-role-cursor ((interactor Interactor)
(role Interactor-Role))
"The default cursor"
(xlt:window-cursor (interactor-window interactor) :target))
I did certainly benefit from some of the runtime errors generated as a
result of the type declarations of some of the defmethods and defuns in my
efforts to update the clx parts of the software.
What is best practice, then, as regards trying to provide useful
type-related information associated with generic functions? Or have I been
so brain-damaged by C++/Java/etc that I am thinking about the problem-space
entirely the wrong way, and thus my solution-space question is entirely
meaningless?

The portable equivalent would be
(declaim (ftype (function (interactor (or interactor-role null)) xlib:cursor)
interactor-role-cursor))