How about, when trying to decide "what is lisp" or to apply "lispp" to
some _thing_, we just go very low level and somewhat retro and mostly
informal?

As a straw-man: a lisp is any language implementation which includes a
run time system with some recognizably lispish types (cons pairs,
numbers, symbols) having their familiar properties (latent typing,
gc-based memory management), and implemented in a recognizably
traditional way (or a brilliant new way, worthy of being added to the
design space).  In the language implemented, programs are expressed in
s-exp syntax and there are some useful senses (for which we don't need
to draw a precise line defining "useful") in which programs are
manipulatable as basic data structures (e.g., expressions as lists).
All the usual Common Lisp implementations are clearly lisps and it's
hard to imagine someone contorting themselves enough to implement a
Common Lisp that isn't a lisp (contrast with a recent "Scheme in
Javascript" that appeared on c.l.s. -- if somebody said "That may be
Scheme but it isn't a lisp" -- I'm not sure why anybody would bother
disagreeing).

We can say that there is a near-but-not-quite consensus among lisp
hackers that some things are better than other things in an
implementation.  For example, an implementation that let's you
evaluate a list as an expression is expected -- and implementations
that don't provide that or provide it poorly are, at the very least,
pretty extreme outliers.

"Common Lisp" and "Scheme" aren't lisps at all.  They are the names of
standards which a lisp may or may not implement.  Another
near-but-not-quite consensus is that Common Lisp has the far larger
commercial significance at the moment, and the greater amount of
practical experience behind it -- and that it's naive to respond to
Common Lisp by saying things like "But Scheme is so much _cleaner_ --
why don't you agree that Common Lisp sucks?".   We can acknowledge
that it has been the experience of people deeply involved with Common
Lisp that, unreasonable as it may sound, they have had to put up with
a lot of such responses over the years.

With this rather retro mostly-operational view of "what is lisp" we
can make perfect sense of statements like "Dylan is sorta-kinda-lisp
but diverges in these ways ...." or "Emacs lisp started out as a
really minimalist lisp and remains a kind of strange dialect -- but it
works _fairly_ well for it's specific applications and it's intersting
to examine why that is" or "delta(Python,lisp) keeps shrinking but
it's not clear that Python really converges on lisp".

And I can say "Hey, I'm interested in making a lisp that is a lisp-1
and _generally_ very Scheme-like; I'm not entirely sure I want (eq?
#f '()) to be false; I'm not entirely sure I really want call/cc."
And having said that, in c.l.l. no less, I might have a discussion
about why I'm leaning in those directions without having the majority
replies being a rightous forensices from Common Lisp bigwigs.

There's a heck of a lot of verbal cleverness on this list.  It seems
to be a point of pride and, indeed, personally I think it's kind of
neat.  But it's also pretty tedious after a while.  Too often it
supresses, rather than enhances, actual interesting discussion.

As straw men go, that one looks reasonably well built (or did before I
truncated it; please read the original before replying to this post if
you want to respond on this point).

I'd add something, though: IMO, a lisp is not _just_ a language
implementation; it's also an environment - or at least, shapes and is
shaped by the environment.  For example, supppose a language
implementation that was otherwise Lispish, but didn't allow function
redefinition, or that allowed it but without affecting old callers.
It sounds like a small divergence, but it radically affects the
environment, because it reduces the utility of interacting with the
system by about 97%.

Now, I imagine that some time in the distant past people have written
lisp implementations that run in batch mode or need input on punched
cards, or for some other similar unfriendly high-latency environment,
and I daresay they did this because they had to and we shouldn't
retrospectively deny them the "lisp" tag, but I'm also quite definite
that if anyone were to ask me about the Lispiness of some new or
proposed language, they would get points deducted for doing things
that break it for interactive use.

All hail macroexpand-1

-dan

--

--

Is Scheme seen as an insurgent language? Steele and Sussman traitors?
This is starting to make some sense.

If so, perhaps these Lispniks should take consolation from Scheme being
a failed experiment and just lighten up. Steele and Sussman were wrong.
They created something small, yes, and with appeal to some who go for
the short spec, but that is as far as it went. The CL crowd voted with
its feet and stood on the mother ship. Game over.

--

Perhaps I was too subtle; I mean precisely to go on the offensive.
Apparently a few lispniks are on their heels over this kind of bullshit
from the comp.lang.scheme FAQ:

"Advocates of Scheme often find it amusing that the entire Scheme
standard is shorter than the index to Guy Steele's "Common Lisp: the
Language, 2nd Edition".

Apparently these geniuses think it matters one whit whether the spec in
its entirety can be carved on the head of a pin. Well, jeez, what was
wrong with the 6502 assembler instruction set?!!

In the next breath they concede:

"Scheme is often used in computer science curricula and programming
language research... Common Lisp is often used for
real world programming..."

Surprise, surprise! You want to know why your toy language does not
scale? <sigh>

Schemers! Lay down your arms and return to your multiple namespaces.
This amnesty expires when we prevail anyway without your numbers.

:)

--

I've seen this statement ("using the full power of [Lisp]") a lot.  In
my (limited) experience, it seems to show up most often in
advocacy-type discussions about the incredible usefulness of macros.
"We can write code to write code, and use the full power of Lisp to do
so."  It makes me curious -- how often has the person using the phrase
fully demonstrated Lisp's power to his audience, before showing them
macros?

As an example, if you created a new C pre-processor that did macros in
a Lispier way (i.e. manipulated C code with C), and told me "and you
can use the full power of C to do it", well, knowing a little C, this
would not in-and-of-itself impress me.  In the same way, if I knew a
lot of C but not any Lisp, and you told me about macros and talked
about "the full power of Lisp", but hadn't demonstrated said power in
other examples, I think I'd tend to discount such statements as
relatively meaningless.

Just a thought for you advocates out there ...

One could imagine a preprocessor that uses a more elegant syntax for
macros only, and generates plain C from them, but that would be designing
a completely different language, compiling to C...

Regards,

During my talk in which I reinvented half of Cells, someone watching
closely said, "I could do those macros in C". I looked, and sure enough
the few I had done simply used token substitution. So then I tossed off
"defmodel Lite" a macro which expanded almost directly into defclass,
then wrote wrapper methods and special cell macros for each slot.

Now for my point: I didn't use anything fancier than mapcar and
destructuring-bind, but the bloke still said, Aha! OK, d-b is pretty
cool, but to him the key thing was simply stepping above substitution
and using the host language to write code.

--

Understandably, academic language research and teaching has moved in the
direction of languages whose formal descriptions are suitably tractable -
which, as you may have noticed I enjoy pointing out, is what McCarthy was
originally trying to create with Lisp.

Imagining that somehow, if Scheme simply went away or hadn't existed in the
first place, that academia would focus instead on Common Lisp, is wishful
thinking at best.  CL and Scheme address different domains, even if there's
an area of overlap (of arguable size).  Their similarities could be a
strength, though, if you allow it.

Anton

Scheme never got used enough for steps two and three to happen, and what
would be the point? CL is scheme plus steps two and three. So Schemers
dig in their heels forever marginalized, consoling themselves with their
tiny little specs.*

:)

--

I guess I really want to say: If you want to do Lisp advocacy, and in
particular talk about the power of macros, *show* some of the power of
Lisp instead of talking about it.  That's all.

Another item missing from CL are continuations, which regardless of their
direct Real World utility, have a great deal of importance for language
implementations, as evidenced by influential books like Appel's "Compiling
with Continuations".  The applicability of these sorts of compilation
strategies extend way beyond academia.

Although you don't need first-class continuation capture in a language to
implement these sorts of strategies, it certainly helps in teaching and
learning about such things, not to mention simplifying development of
non-standard language control constructs.

Scheme is a Lisp dialect|variant which has these features, and others.
Consider this a way of keeping Lisp competitive in the academic world, and
preventing Lisp from being completely shut out of academia, or relegated to
the occasional AI department.

All fully-fledged Scheme implementations have an object system.  Some of
them even integrate with Java's object system pretty neatly, so what you
consider a disadvantage may actually be a strong point.

We need a bumper sticker: "Make (new) datatypes, not languages." Cells
don't make you adopt anything other than Cells. Steele always makes you
take up a new language.

:)

--

What Sussman & Steele did was to improve on some choices that were made
early in Lisp's history, when the lambda notation was first borrowed from
Alonzo Church.  McCarthy says at:
http://www-formal.stanford.edu/jmc/history/lisp/node2.html that "it seemed
natural to use the [lambda]-notation of Church (1941). I didn't understand
the rest of his book, so I wasn't tempted to try to implement his more
general mechanism for defining functions."

It turned out that that Church's "more general mechanism for defining
functions" was a lot more important than might have been imagined.  Lisp's
original lambda was a little broken, and Sussman & Steele showed how to fix
it.  Such a fundamental fix creates a new language, whether it's made to an
existing variety of Lisp or implemented in a brand-new variety.  See below.

Once a useful new feature has been identified, the question then becomes
whether that feature belongs in existing languages.  CL and some other Lisps
answered "yes" for lexical variables, but "no" for continuations, for
example.  Such choices are a central reason why different languages exist -
if you could just throw all imaginable features in a bucket, and call it a
language, we'd all be using that language - which would truly be a ball of
mud.  But the reality is that once you throw certain features in the bucket,
some other features will no longer fit well, if at all.  That's why we have
lots of different languages.

Many of those different languages aren't, by any stretch of the imagination,
Lisp.  But Lisp has demonstrated the potential to cover a larger part of the
possible design space than many languages.  But it can't do that by picking
a single set of features.  If it does that, then any language without that
exact set of features won't be Lisp, and Lisp loses by that - loses
flexibility, loses potential, and loses mindshare, not to mention
encouraging the proliferation of non-Lisps.

For Lisp to reach its true potential, it has to have more than one variant,
some of which will have features incompatible with other variants - whether
it's the number of namespaces, the presence of absence of some features, the
way in which they treat program source, or something else.  The fact of
these incompatibilities says nothing other than that different tradeoffs
were made in a larger design space - known, to some, as Lisp.

yes, that's the thing. let's have a language whose spec fits on the head
of a pin. no, you wouldn't want to do anything with it, that would
totally ruin the pretty little spec. hang on, do we really need that
"if" statement? where are those scissors...

aflac!!!!!!

Oh, well, i guess this "gee, it's good for research" consolation prize
to the Scheme insurrectionists is tantamount to an admission of defeat.
We accept.

:)

--

For one thing, the only sense in which Steele abandoned anything is that he
left both communities.  ;)

However, there is an underlying problem that there is NOT a canonical notion
of "simple".  (For an elaboration, read my paper on equality. The same issues
are in play.)  In brief, you have to say "simple in what way?"

I claim that "simplicity of implementation" necessarily sacrifices
"simplicity of programming", and vice versa.  Scheme often uses the
unadorned term "simple" as if it were "obvious" that "less to learn"
was better.  ("simple to learn" is probably some third axis, actually.)

While one can draw a three dimensional space with ease of programming
on one axis, ease of learning on another, and ease of implementation
on a third, this is deceptive because it suggests that it's easy to
locate an object anywhere in that space. These axes are somewhat
interdependent, and so making it easier on the implementors usually
makes things harder on the users, and vice versa.  Some counterexamples
are possible, but there are reasons, I think, that most human languages
are not like esperanto and loglan, and that even after the development
of these so-called "simpler" languages, humans didn't flock to their use.
Humans are equipped in hardware to spend a longer learning and to hold
a large amount of information in exchange for easier programming.  So the
claim that CL is "less simple" addresses the language, not the programs.

I personally find CL programs simpler to read than Scheme programs in
most cases exactly for the same reason that I would expect to find a
copy of Gone with the Wind harder to read in Esperanto than in English.
The fewer words you have to work with, the more heaps of modifiers and
early little definitinos you need to "catch up" with a larger language.

There is some tiny fussing about the "size of the core" but that's all
red herring because the actual difference between the CL core (not normally
separately articulated) and the Scheme core is tiny, and is not by any
means the bulk of what you spend your time learning about when programming
either language.

I don't care to characterize Scheme as failed, though I have heard this
characterization.  If there are extant happy users, that's fine with me.
I have no deathwish for Scheme.  Just not a desire to be forced to use it.

And, moreover, in the context of this message, I have a desire not to be
forced to use their metric of "simple".

Thus people who hold to Tilton's definition of success cannot
proclaim Common Lisp a success except by denying that Scheme is
a Lisp.

Incidentally, another way of looking at it is to say that ANSI would
likely not, as a procedural matter, have allowed two co-existing
standards for the same language.  So, one might conclude, that ANSI,
at least, must believe that Scheme and Common Lisp are not the same
language.

Not that I (nor anyone) is empowered to speak for ANSI.  Just
speculating using the same power of pseudo-logic (or actual logic
applied to pseudo-facts) that Will was using.

1) Scheme: First year language (freshman undergraduate) used to teach
basic computing paradigms. Has very little cruft to get in the way.
Also useful for shock value. Its different from languages that people
may know already (like BASIC) so its useful for teaching ideas without
past experience getting in the way.

2) Java: Its a very useful teaching language. Its has lots of
libraries available and good documentation. Because of the easily
accessible libraries, students can get started on some "interesting"
programs (read: games) that provide something similar to the software
they see normally used on computers. CL might be a good fit here, as a
powerful language with a wide range of capabilities, but hey, you
gotta throw a bone to the commercial market somewhere, right?

3) Smalltalk: Useful for teaching OOP because its pure OOP, without
anything else to get in the way.

4) C: Everybody should know C. It gives a very good understanding of
how machines work at the lowest levels. The first C assignment in our
particular course has students wade through SPARC assembly trying to
figure out what each statement does.

I don't really know what else they use at our school, but I know that
even MIT and Caltech push languages as varied as Ocaml, Scheme, and
Eiffel, depending on a professor's particular bent.