[comp.lang.lisp] weird common lisp feature sic

john@mingus.mitre.org (John D. Burger) (02/22/91)

lkramer@brahms.udel.edu (Laurence Kramer) writes:

> [Misinterpretation of bug in KCL as CL semantics deleted]

> Do people programming in common lisp really need their heads
> examined? No, they should be pitied because their options are few.

> In an ideal world we would all be programming in muLisp.  It is
> beautiful, small, efficient, extensible, and really embodies the
> spirit of what Lisp should be.  Two big problems: it is imprisoned
> within DOS's 640k barrier and isn't portable.

Gee, it sounds like my options would really be increased if I used
muLisp.



--
John Burger                                               john@mitre.org

"You ever think about .signature files? I mean, do we really need them?"
  - alt.andy.rooney

kers@hplb.hpl.hp.com (Chris Dollin) (02/26/91)

Barry Margolin says (amongst other things):

   The original question was about KCL, which is an implementation of Common
   Lisp.  Common Lisp *does* guarantee left-to-right order of evaluation, just
   as its predecessors Maclisp and Zetalisp did.  Scheme doesn't specify the
   order of evaluation of function arguments.

Where does CLtL guarentee L-to-R order of evaluation? [I've looked in CLtL I,
and didn't find anything that did guarantee L-R, but I could have missed it. I
*did* find 5.2.2, p61, which talks about when a function represented by a
lambda-expression is applied to some arguments and says the args and the
parameters are *processed* L-R; but that doesn't mean they have to be
*evaluated* L-R. Does it?]
--

Regards, Kers.      | "You're better off  not dreaming of  the things to come;
Caravan:            | Dreams  are always ending  far too soon."

lkramer@brahms.udel.edu (Laurence Kramer) (02/26/91)

It seems like you didn't read the rest of my message.  My point was that
everyone would be better off programming in muLisp if it were portable.

barmar@think.com (Barry Margolin) (02/27/91)

In article <KERS.91Feb26132521@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>Where does CLtL guarentee L-to-R order of evaluation? [I've looked in CLtL I,
>and didn't find anything that did guarantee L-R, but I could have missed it. I
>*did* find 5.2.2, p61, which talks about when a function represented by a
>lambda-expression is applied to some arguments and says the args and the
>parameters are *processed* L-R; but that doesn't mean they have to be
>*evaluated* L-R. Does it?]

I was hoping no one would remember this.

CLtL never comes right out and says that arguments are evaluated
left-to-right.  However, there are enough references to "the usual
left-to-right order" that it is clear that this was an oversight.  For
example, CLtL p.194, when describing how the order of processing of
arguments to arithmetic functions may be rearranged according to
associativity and commutativity, says that this doesn't change the order of
evaluation, which "is always left to right, as in all Common Lisp function
calls."  And, p.97 says, "SETF carefully arranges to preserve the usual
left-to-right order in which the various subforms are evaluated."

Interestingly enough, CLtL2 doesn't seem to have corrected this oversight.
However, another passing reference was added: p.75 says, "while the
arguments in a function call are always evaluated in strict left-to-right
order, ...".  The use of the word "while" implies that this clause is
restating an already-established fact.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar