Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: welch@CIS.OHIO-STATE.EDU (Arun Welch)
Newsgroups: comp.lang.clos
Subject: Re: Beefs about lambda list congruency
Message-ID: <9103181446.AA00181@sacral.cis.ohio-state.edu>
Date: 18 Mar 91 14:46:05 GMT
Sender: welch@tut.cis.ohio-state.edu
Distribution: inet
Organization: CommonLoops
Lines: 45

[Our mailer died, here's a remailing of something that didn't make it
through the gateway...arun]

Date: 16 Mar 91 20:00:16 GMT
From: andreasg@sigi.Colorado.EDU  (Andreas Girgensohn)
Organization: University of Colorado, Boulder
Subject: Re: Beefs about lambda list congruency
Message-Id: <1991Mar16.200016.24580@colorado.edu>
References: <9103151842.AA03261@clouseau.mitre.org>
To: commonloops@cis.ohio-state.edu

In article <9103151842.AA03261@clouseau.mitre.org> john@LINUS.MITRE.ORG writes:
>kramer@wotan.ai.toronto.edu ("Bryan M. Kramer") writes:
>
>  So in summary, my complaint is that the number of
>  number of required parameters has to be the same.
>
>The problem seems to be that you are thinking of methods as analogous
>to functions.  They are not.  A method is a PIECE of a function, a
>generic function.  In particular, it is NOT possible in CLOS to apply
>a method object in isolation, via FUNCALL or APPLY.
>
>So, you seem to want the generic function to take different numbers of
>required arguments at different times.  Huh?  If they're different at
>different times, then they're not always required.  So, you want some
>of the required arguments to be optional.  But only sometimes.
>
>Is this starting to sound somewhat problematic?
>
>John Burger

I would prefer that different methods of the same generic functions could have
different numbers of required parameters.  The selection of the applicable
method(s) would depend on the number of parameter in addition to the types of
the parameters.  I would also like to be able to specialize optional
parameters.  This might produce some problems for the ordering of methods but
only people who would have methods with different numbers of parameters would
encounter these problems.  I think that would have been a nice addition to
CLOS that wouldn't have disturbed people who insist on congruent lambda lists
at all (the CLOS implementors would have had more work).  But I guess it is
too late now, I can live with congruent lambda lists.

Andreas Girgensohn
andreasg@cs.colorado.edu