Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!cambridge.apple.com!alms
From: alms@cambridge.apple.com (Andrew L. M. Shalit)
Newsgroups: comp.lang.lisp
Subject: Re: In defense of call/cc (and a plug for T)
Message-ID: <ALMS.91Feb19173808@ministry.cambridge.apple.com>
Date: 19 Feb 91 22:38:08 GMT
References: <1991Feb12.233157.20820@elroy.jpl.nasa.gov>
	<1350036@otter.hpl.hp.com> <4154@skye.ed.ac.uk>
Sender: news@cambridge.apple.com
Organization: Apple Computer Inc, Cambridge, MA
Lines: 32
In-reply-to: jeff@aiai.ed.ac.uk's message of 18 Feb 91 14:36:27 GMT

In article <4154@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:

   BTW, I partially disagree with ram+@cs.cmu.edu (Rob MacLachlan), who
   wrote:

      Well, I agree that optionals are mostly a loss, but you shouldn't
      be paying any penalty other than compiler complexity.  I am
      convinced keyword args are a big win for complex interfaces.
      Positional arguments start to lose it above 5 or 6 arguments.

   One way to handle the many argument problem would be to make
   keywords part of the programming environment (eg, the editor
   would let you specify parameters that way) rather than having
   them exist at run-time.  All parameters could then be specified
   by keyword rather than positionally.  However, there would be
   difficulties with APPLY (either there are keywords in the list
   of arguments or else we're back to positional) and we'd be moving
   towards a situation where source code wasn't readable without
   the aid of some clever environment.  So in this (as in many issues),
   I think CL has made a reasonable compromise.

In addition to the problems you mention, this would introduce
order-of-evaluation problems.

Common Lisp specifies left-to-right evaluation, so the following
two calls are different:

(frob :a foo :b (incf foo))
(frob :b (incf foo) :a foo)

    -andrew
--