In article <3070479470939233@naggum.no>, Erik Naggum <erik@naggum.no> wrote:
>
>| Lisp isn't a good system programming language because it's too hard to
>| write efficient programs in it and it doesn't provide good low-level
>| access to machine facilities.
>
>I have criticized the use of "Lisp per se" in comp.lang.lisp, as it seems
>that "Lisp" means some sort of proto-Lisp to many people, including you.
>since there is no such language, any discussion of Lisp that fails to be
>precise in which Lisp it discusses is literally devoid of meaning. that
>you draw wide-ranging conclusions about an unspecific language is perhaps
>significant, perhaps not. in either case, it is disconcerting that you
>don't bother to be specific.
Sorry about the "Lisp per se" thing---I started that. I was trying
to make things clearer. The point I was making was that Common Lisp
gets a very bad rap for being "too big", "not interoperable" and
what have you. (Of course Common Lisp doesn't look so big anymore
now that we have C++.) Often people say that Lisp is this and Lisp is
that, when they really mean Common Lisp if they know what they're talking
about at all.
I was just making the point that a Lisp doesn't have to be big. (For
example, standard Scheme.) So if you're designing a language of your
own, as Ousterhout did, you don't have to take the whole package
of Common Lisp. You can also make it interoperate Tcl-style, if you
want to.
People often err the other direction, too. The most recent versions
of several language textbooks propagate misinformation like "Lisp only
has one data type" (which was never true) and "Lisp is dynamically scoped"
(which hasn't been true for a while) and "garbage collection is disruptive"
(which needn't be true if you get the right kind of GC) and "Lisp is a
special-purpose language for AI." I've even run into a person who bashed
Lisp both ways---saying it's bloated and slow, and only has one datatype!)
So to clarify what I mean by "Lisp per se", it's something like
A simple and powerful language with
1. dynamic typing (it is not really "untyped"--exactly the
opposite, because every value has a definite type),
2. lexical scope by default
3. higher-order procedures that are closures,
4. the ability to define new constructs in terms
of old ones, via programmer-specified transformation
(macros, which are far more powerful than macros in
most other languages),
5. some handy data types, notably pairs (cons cells)
and symbols (uniquified strings), and
6. (typically) support for interactive execution
with an interpreter, or a compiler that compiles
expressions and runs the code immediately.
7. side-effects (i.e., assignments) are available.
No one of these features is essential, but this is the general
area of design space.
#2 deserves some explanation. The original Lisp was dynamically
scoped, but that was an accident. (McCarthy said it was just
"a bug", and that Lisp should have been lexically scoped, as
most Lisps are now, including Scheme, Common Lisp, and EuLisp.)
As originally intended, most modern Lisps are lexically scoped,
just like the Algol descendents (Pascal, Modula, Simula, C)
and the Lambda calculus. (Lexical scope is more useful in Lisps
because procedures are closures.)
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
|