From: Tim Larkin
Subject: CLOS congruent lambda lists
Date: 
Message-ID: <1j6nv7INNkje@newsstand.cit.cornell.edu>
I have just taken up the task of converting a large program from Flavors 
to CLOS (inspired by the rumor that Symbolics heads for Chapter 11).
Flavors
generic methods have no restriction on their lambda lists, that is, if a 
generic function has the name foo, than each foo method can accept any 
arbitrary lambda list; there need be no similarity between them. So I can 
define (foo a) and (foo a b c) and (foo a b &rest args). I fully 
exploited this freedom.

Now it seems that in CLOS we observe the influence of the practitioners
of 
bondage-and-discipline. All methods for a generic function must have 
congruent lambda lists, so we cannot have (foo a b c) and (foo a). We 
cannot even have (foo a &rest args) and (foo a b c d e). This strikes me 
as a pretty stupid innovation, but I guess it doesn't matter how stupid 
it appears to me.

I have come up with one conversion strategy which seems fairly easy to 
implement, albeit prolix. I define all generics with uncongruent lambda 
lists as equivalent to (foo self &rest args). Then the first form of the 
body does a destructuring bind to extract the (former) parameters from
the 
&rest list. 

Has anyone found a better way?

Tim Larkin
Federal Nutrition Laboratory
Tower Road
Ithaca, New York
····@cornell.edu
607-255-7008
From: Joe Konstan
Subject: Re: CLOS congruent lambda lists
Date: 
Message-ID: <C0x5AJ.3HG@news2.cis.umn.edu>
In article <············@newsstand.cit.cornell.edu>, Tim Larkin 
<····@cornell.edu> discusses congruent lambda-lists:
|> I have come up with one conversion strategy which seems fairly easy to 
|> implement, albeit prolix. I define all generics with uncongruent lambda 
|> lists as equivalent to (foo self &rest args). Then the first form of the 
|> body does a destructuring bind to extract the (former) parameters from
|> the 
|> &rest list. 
|> 
|> Has anyone found a better way?

Not a better way, but I thought I might point out why you don't see the value
of congruent lambda lists in your example.  CLOS allows discrimination on any
or all required arguments.  Further, specifying the argument without a type is
equivalent to specifying the argument with type t--i.e., no guarantee that
that a different method doesn't discriminate on that argument.  Accordingly,
the lambda list congruence is needed to prevent ambiguities in method
discrimination.

I'd prefer requiring a defgeneric that explicitly lists the fields that are
usable for discrimination, but I can see arguments against that too.

As for your solution, it is fine for generic functions that always are 
dispatched on the first argument.  Another choice you might want (with some
performance penalty) is the use of keyword arguments since
&allow-other-keywords allows different sets of of keywords to be congruent.

Joe Konstan
·······@cs.umn.edu