Lisp Signatures...

Here is a simple example of what I'm referring to. The stuff mentioned from Tobias is very close, if perhaps a little too elaborate. I just finished hacking an example, now that I have seen some of the offerings and I gained a better image in my mind of what I needed:

Example protocol specification:

(protocol:define-protocol btree-protocol (btree node)

(:type

(height integer)

(index integer)

(count integer))

(:signature

( node-height (node) => height)

( node-fill-pointer (node) => index)

( (setf node-fill-pointer) (index node) => index)

( node-list-cell (node index) => t)

( (setf node-list-cell) (t node index) => t)

( node-capacity (node) => count)

( copy-node-list-cells (node index node index count) => nil)

( root-node (btree) => node)

( (setf root-node) (node btree) => node)

( items-count (btree) => count)

( (setf items-count) (count btree) => count)

( compare-fn (btree) => function)

( key-fn (btree) => function)

( make-node (btree height) => node)

( discard-node (btree node) => nil)

))

;; --------------------------------------------------------------------------------------

;; Define all the methods here...

....

;; --------------------------------------

;; After methods have been defined...

(protocol:implements-protocol btree-protocol (file-btree file-node))

;; --------------------------------------

The protocol specification names the protocol, here btree-protocol, and the parameters are the names of types (classes) that will parameterize the protocol specification. Below that introduction we have two optional groups. The first one named :TYPE allows the introduction of named types to help clear up the intent and meaning of the following signatures. The :SIGNATURE section names a bunch of methods, their argument types, and the bit "=> type" is just for decoration at this time.

Then later, after the methods have actually been defined, I attempt to state that the methods that I have just defined satisfy the btree-protocol, with actual classes named FILE-BTREE and FILE-NODE as parametric types for the protocol. This causes the system to run through the protocol signatures and verify that indeed there are methods with those stated signatures, and using the concrete types FILE-BTREE and FILE-NODE. If not, then an error message is printed and the loading halts.

All of this was accomplished in about 100 LOC, including comments and whitespace...

Dr. David McClain

Chief Technical Officer

Refined Audiometrics Laboratory

4391 N. Camino Ferreo

Tucson, AZ 85750

email: dbm@refined-audiometrics.com

phone: 1.520.390.3995

web: http://refined-audiometrics.com

Re: Lisp Signatures...

Hi David,

Nice stuff. I think one reason that this protocol stuff is less common in Lisp (aside from general culture differences) is that it's not obvious how to extend it to generic functions. I.e., methods aren't associated with objects, they are associated with functions. Even so, I like the idea of having a general tool like this for Lisp.

Are you going to post the source code somewhere?

On Dec 8, 2008, at 3:54 PM, David McClain wrote:

Here is a simple example of what I'm referring to. The stuff mentioned from Tobias is very close, if perhaps a little too elaborate. I just finished hacking an example, now that I have seen some of the offerings and I gained a better image in my mind of what I needed:

Example protocol specification:

(protocol:define-protocol btree-protocol (btree node)
  (:type
   (height integer)
   (index integer)
   (count integer))
  (:signature
   ( node-height (node) => height)
   ( node-fill-pointer (node) => index)
   ( (setf node-fill-pointer) (index node) => index)
   ( node-list-cell (node index) => t)
   ( (setf node-list-cell) (t node index) => t)
   ( node-capacity (node) => count)
   ( copy-node-list-cells (node index node index count) => nil)

   ( root-node (btree) => node)
   ( (setf root-node) (node btree) => node)
   ( items-count (btree) => count)
   ( (setf items-count) (count btree) => count)
   ( compare-fn (btree) => function)
   ( key-fn (btree) => function)
   ( make-node (btree height) => node)
   ( discard-node (btree node) => nil)
   ))

;; --------------------------------------------------------------------------------------
;; Define all the methods here...
....

;; --------------------------------------
;; After methods have been defined...

(protocol:implements-protocol btree-protocol (file-btree file-node))

;; --------------------------------------

The protocol specification names the protocol, here btree-protocol, and the parameters are the names of types (classes) that will parameterize the protocol specification. Below that introduction we have two optional groups. The first one named :TYPE allows the introduction of named types to help clear up the intent and meaning of the following signatures. The :SIGNATURE section names a bunch of methods, their argument types, and the bit "=> type" is just for decoration at this time.

Then later, after the methods have actually been defined, I attempt to state that the methods that I have just defined satisfy the btree-protocol, with actual classes named FILE-BTREE and FILE-NODE as parametric types for the protocol. This causes the system to run through the protocol signatures and verify that indeed there are methods with those stated signatures, and using the concrete types FILE-BTREE and FILE-NODE. If not, then an error message is printed and the loading halts.

All of this was accomplished in about 100 LOC, including comments and whitespace...

Dr. David McClain
Chief Technical Officer
Refined Audiometrics Laboratory
4391 N. Camino Ferreo
Tucson, AZ 85750

email: dbm@refined-audiometrics.com
phone: 1.520.390.3995
web: http://refined-audiometrics.com

Gary Warren King, metabang.com

Cell: (413) 559 8738

Fax: (206) 338-4052

gwkkwg on Skype * garethsan on AIM