Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!newshub.sdsu.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!waldorf.csc.calpoly.edu!kestrel.edu!mcdonald
From: mcdonald@kestrel.edu (Jim McDonald)
Subject: Re: Comparing productivity: LisP against C++ (was Re: Reference Counting)
Message-ID: <1995Jan6.210632.27234@kestrel.edu>
Sender: mcdonald@saker.kestrel.edu (Jim McDonald)
Nntp-Posting-Host: saker.kestrel.edu
Organization: Kestrel Institute, Palo Alto, CA
References: <19941203T221402Z.enag@naggum.no> <BUFF.94Dec15103904@pravda.world> <D0xAIp.3Dn@rheged.dircon.co.uk> <vrotneyD11MDv.Ks7@netcom.com> <vogtD12y8D.HLL@netcom.com> <3d5alh$6j7@celebrian.otago.ac.nz> <3d8j9r$cm9@celebrian.otago.ac.nz> <1994Dec23.020527.25551@kestrel.edu> <3dg0d2$m7f@celebrian.otago.ac.nz> <1995Jan4.034958.2309@kestrel.edu> <3ei9dv$mig@celebrian.otago.ac.nz>
Date: Fri, 6 Jan 1995 21:06:32 GMT
Lines: 81
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:106212 comp.lang.lisp:16299

In article <3ei9dv$mig@celebrian.otago.ac.nz>, nmein@bifrost.otago.ac.nz (Nick Mein) writes:
|> Jim McDonald (mcdonald@kestrel.edu) wrote:
...
|> : But running a program with the wrong number of arguments is just an
|> : instance of calling a function with the wrong number of parameters.
|> : In the lisp example, the top level invocation looks like any other
|> : function call, whereas in the C example, two different syntaxes are
|> : used.  
...
|> When I thought of my "challenge" I deliberately made it simple
|> (trivial?). Unfortunately, it was so simple that a couple of issues seem
|> to be blurred. The top level C++ function has a formal argument list of
|> length 2. The second formal argument in this list is itself an argument
|> list (actual arguments provided by the user, via the command line).
|> The Lisp top level function also has a formal argument of length 2.
|> Because I specified that any (command line) actual argument list length 
|> other than 2 was an error, it appears to some people that the Lisp 
|> reader's (is that the right term?) handling of argument list errors
|> is equivalent to that in the C++ example.
|> 
|> That this is not the case is clear if you imagine that the user was
|> permitted to supply 0, 1 or 2 (command line) arguments. (In Unix terms,
|> the command line syntax would be "invert [infile [outfile]]").
|> The C++ top level function would have the same formal argument list, and
|> now the Lisp top level function would presumably have a list as its only
|> formal argument, and would require argument list processing code similar
|> to that of the C++ example.

It would be possible to define a lisp function as you say, using a
rest argument, but Common Lisp also allows optional arguments, so 
one would more likely use a definition something like:

  (defun invert (&optional (infile  *default-image-input*) 
                           (outfile *default-image-output*))
     ...)

This allows you to make all these calls with equivalent effects:

  (invert) 
  (invert *default-image-input*)
  (invert *default-image-input* *default-image-output*)

Or you could do this to override the first or both defaults, respectively:

  (invert my-input)
  (invert my-input my-output)

If you wanted to override the second but not the first, you would
probably define the function to allow keyword arguments -- more
flexible, but more verbose.  You can mix normal, optional, keyword,
and rest arguments.

Again, this is all handled standardly, so each user doesn't have 
to write their own code to check for wrong number of arguments
or for calling a function with the wrong keywords.  And there is
a standard way to provide optional default values (as shown above)
plus an optional flag indicating if the default value needed to 
be used.  None of which prevents you from doing your own argument
checking, but I've written at most a few dozen functions like that,
out of tens of thousands where the defaults were just fine.

There is now over 30 years of development for lisp programming
environments, and current dialects (especially Common Lisp) are 
successors to a wide range of experimentation with different 
dialects in 70's, so most of the rough edges that get in the way
of developing code have long since been worn smooth, and common
paradigms have been recognized and standardized.  As a result,
the default behavior provided by most lisp environments in various 
situations is almost always better than what a normal user would
program by hand.  C++ has a far shorter history, so it has not
yet evolved to that comfort level.  But it could, and the C++
community would do well to study how the lisp community has dealt
with such issues.  [Which is not to say they need to blindly
emulate lisp--just that they can avoid reinventing some wheels.]







