Re: format for description of generic functions in chapter 2

[Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>]

         Actually, I disagree with one detail of what Gregor said.  I can't understand
         why lambda-list congruence should be restricted to standard generic functions
         and standard methods.  To me lambda-list congruence seems equally applicable
         to all generic functions and methods, and furthermore it's hard to see how
         generic functions could work or users could call them if there wasn't
         lambda-list congruence.  Thus I think congruence is part of the contract of
         add-method, and should not be demoted to association with a
         particular method.
     
     I (Gregor) still disagree with you about this.  More in a separate
     message.
        
I will be interested in seeing what prompted Gregor to disagree.  It
seems to me that it is bad if you have to know the class of a generic
function, and find out about the lambda congruence rule for this class,
in order to know that your program is calling it properly. I doubt that
you will gain much power from changing the lambda list congruence rule
and it seems that this "flexibility" will bring confusion. 
     
         Here's the big problem with this new breakout of methods and generic
         functions:  We are uncovering a significant amount of confusion about
         what is the contract of a generic function, versus what is a property
         of particular methods for that generic function.  In effect all of
         the issues and uncertainties surrounding meta-objects have suddenly
         leaked into the part of the document that we thought was almost
         finished.  I'm really opposed to that because I think it sets us back
         a long way.  It's really not necessary to resolve all those issues
         to get something that is entirely useful to someone who is just going
         to call these generic functions and not define new methods for them.
         On the other hand, I do think the introduction of the method signatures
         was a good idea, and I think the format as described in the quotation
         from RPG above is a good idea.  If we can keep the documentation in the
         style of the sample class-changed writeup, I'll be happy with the new
         format, but if we're going to get bogged down in all these modularity
         issues, I want no part of it.
     
     Its true that this new breakout causes us to confront some meta-object
     stuff which we don't really want to have to work out in the next 5 days.
     But, it may be alright if we just take our best stab at it and then fix
     it up later.  Here's why.  We believe that for the time being, the only
     kind of programming we are really sanctioning is programming that calls
     these generic functions (in cases like add-method).  In these cases, we
     should take our best shot, but if in the course of writing the meta spec
     we decide we need to move something from method to gf or vice versa we
     can.  Because as far as the user who just calls generic functions like
     add-method, the behavior of the generic function as a whole will be
     unchanged.  As a point of strategy, where we are unsure, behavior should
     be ascribed to the generic function rather than the one of the methods.
     
I like this strategy. I don't have any problems with the agreement
reached in each case. 

Patrick.