Re: Difficulty with lambda-list congruence...

[REEDER%kebc.icl.stc.co.uk@NSFNET-RELAY.AC.UK]

Recent Experience
=================
Our Esprit project (just) survived with an *old* version of PCL and
Lucid until last December - we didn't have the resources to keep
every new PCL/CLUE/CL in-step & debug them.
Just recently we have been evaluating Harlequin's Lispworks environment
with integrated (strict) CLOS...

 Congruence hadn't been a problem before!!

...so we re-read the 'manual' and discovered the "true way".

Coming from a Loops background, we just "sort of made these methods".
There being *NO "global"* limitations other than that the call corresponded
to the actual "method". Indeed, after some mid-project restructuring
of classes, we had actually EXPLOITED the ability to re-use a 
method name with different arguments on a new class as follows:

OLD>>
(defclass tool ()  (...) ) 
	(setq ti (make-instance 'tool...))
(defclass manager () (...) )
	(setq mi (make-instance 'manager...))
(defmethod close ((man manager)(tool-inst tool)  l)...<useful work>)

(close (manager ti) ti '(1 2 3))

NEW>>
(defclass tool ()  ((mgr :accessor manager) )
	(setq ti (make-instance 'tool...))
(defclass manager () (...) )
	(setq mi (make-instance 'manager...))
(defmethod close ((man manager)(tool-inst tool) l)...<useful work>)
(defmethod CLOSE ((self tool) l)...(close (manager ti) self l) )

(close ti  '(6 7 8))

========>> which is NON-CONGRUENT on the GENERIC function CLOSE

=====>> i.e. "illegal".

*BUT* we didn't have to be thorough in finding the  (OLD) calls
 of the form (close (manager ti) ti '(1 2 3)) as they would STILL WORK!

This was a substantial consideration when a review was imminent.

OK, we've now made the names different and it wasn't that hard when
the various component files had stabilized.

I had an illusion shattered - i.e. that an advantage of  CLOS  (over
(say) LOOPS ) was that "methods" were selected on the combination of 
method name & arguments.

My over-interpretation was arose from just considering the leading
arguments (typically objects) and forgetting implementation problems
such as &optional parameters.

So, I was forced to think again about the relationship between
the Generic function approach and the LOOPS-like class + methods approach.
(Ignoring any "package"-smarts...) What seems to have been LOST
by divorcing method-interface-definition from class-definition
(& thus having this congruence requirement ) is the ability to define
classes and associated methods INDEPENDENTLY. So, inevitably,
there will be problems when combining modules into a large system
because the same method name has been re-used...

USER 5 > (in-package 'a :use '(CLOS LISP))
#<The A package, 0/11 internal, 0/11 external>
 
A 6 > (defclass z () (zz))
#<class Z>
 
A 7 > (defmethod grr((s z) p) 42)
#<Method GRR NIL (Z T)>
 
A 8 > (defclass w () (ww))
#<class W>
 
A 9 > (defmethod grr((s w)) 69)

Error: Inconsistent ordering #<standard generic function GRR>, (S),(0 1)
  1 (abort) return to top loop level 0.

Type :c followed by a number to proceed

A 10 : 1 > 

Which makes me very sad.

...and so, Lawrence G. Mayka you have my sympathy w.r.t. &REST  &KEY etc
maintenance and I eagerly await to read any ensuing e-mail
in this regard.

	Mark Reeder,
	ICL Future Systems,
	Manchester M3 2NL