Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: weird common lisp feature
Keywords: read, read-line
Message-ID: <4206@skye.ed.ac.uk>
Date: 21 Feb 91 19:54:03 GMT
References: <12413@helios.TAMU.EDU> <1991Feb21.104336.26012@Think.COM> <18935@brahms.udel.edu>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 50

In article <18935@brahms.udel.edu> lkramer@brahms.udel.edu (Laurence Kramer) writes:
>Permit me to flame a while...  Last week I wrote a message that said
>briefly that people doing AI R&D in C rather than Lisp needed their
>heads examined.  Well, this common lisp "feature" mentioned further
>reinforces another opinion I have:  People developing in common lisp
>need their heads examined.  If I write (foo a) (foo2 b), I would certainly
>expect foo to be evalled before foo2.  As a software developer I shouldn't
>have to worry that the combination of foo and foo2 somehow is different
>than most other functions I know about.  This is certainly in direct
>opposition to the spirit of Lisp programming!

As several others have noted, the problem concerns I/O, not evaluation
order.  I consider it a _bug_ in KCL and usually load in some code
that fixes it.

You shouldn't be so quick to seize on examples of how losing Common
Lisp is, because they might turn out not to be anything of the kind.

>The problem with common lisp is not so much that it is too big, or that it
>was written by a committee, etc.  The problem with common lisp is that
>it was written more with an eye to the compiler than to the interpreter.

This reminds me of something someone in BSI said, that the problem
with Common Lisp was that it had taken too much from procedural
languages.  I suspect rather strongly that when you saw what looked
like an evaluation order problem you thought "Ah ha!  See what happens
when you try to make life easy for the compiler!"  But the truth is
that Common Lisp specifies _more_ of the evaluation order than most
other languages (eg, C).

Let's face it.  Some people don't like Common Lisp and never will.
They have all kinds of reasons for thinking CL is bad.  But it often
turns out that what's behind it is that they have a different idea
of what Lisp should be like and think they are in the true Lisp
tradition while Common Lisp is a deviation.  

If you're used to small, interpreted Lisps, you may not like a Lisp
that enforces compiler-like semantics (eg, lexical scoping).  But
_other_ Lisp programmers were used to compiling their programs and
wrote "for the compiler", so they're glad Common Lisp enforces the
same scope rules in the interpreter.  For example, many MacLisp (and
Franz Lisp) programmers considered the compiler's semantics to be the
real semantics and the use of different scoping rules in the
interpreter to be a bug.

I think it helps to remember that there's more than one good way to do
Lisp.  If people disagree about which way is best, it doesn't mean
that one side or the other needs their heads examined.

-- jd