Yes, well, o.k., I misspoke (or perhaps wasn't specific enough).  Yes, I
know of other Scheme readers (well, at least one) which annotate the source
similarly (e.g., the one in the Rice PLT group's "MrSpidey"). But what I was
referring to is that the user-visible READ *does* accept all legal source
programs, so that Erik's distinction between "prgrams defined by lexical
rules" and "programs defined by S-exprs" is, for all practical purposes, moot.

Now it is certainly the case that one could make a *mistake* in defining a
Lisp (or Scheme) by its lexical representation in such a way that there was
*not* a guarantee of equivalency, but I also suspect that most participants
in this group would consider such a definition badly broken (if only because
of the negative implications on macros).

+---------------
| READ does not do this. In fact, the source program reader doesn't produce
| a typical S expression. Rather it produces a structure of type S-EXPRESSION
| which includes the encapsulated file, line, and character position.
+---------------

Call me naive, but I don't see how this affects the issue... unless there
are files which Stalin [or some other Lisp or Scheme] will accept as programs
which its READ *won't* accept when a user program tries to read them (e.g.,
say, allowing allows "#+<sym>" or "#.<exp>" in "programs" but not in files
parsed with READ). And if there are, I'd call it broken.

-Rob

[p.s. Apologies in advance: Replies to this via email may get a
"vacation" bounce messages while I'm on sabbatical from SGI...]

More precicely it is 4110 loc (.c+.h), which is either 4.1 kloc
or 4.0 kloc, depending on whether you use "kilo" for "thousand"
or 2^10=1024.

--
Dimitrios Souflis                dsouf...@altera.gr
Altera Ltd.                      http://www.altera.gr/dsouflis

  well, no, it means that you need a whole different machinery to read
  Common Lisp than you need to read Scheme.  Scheme was designed in the
  fashion of static grammars, and people frequently implement the reader in
  some other language.  Common Lisp's reader is best written in Common Lisp
  -- it dispatches on characters according to a table, the READTABLE, and
  call out to functions that assemble the various types of objects.  this
  is overkill per excellence for Scheme.  also, Scheme's grammar is defined
  so that (foo 1 2 . ()) is different from (foo 1 2), although the Scheme
  reader cannot detect this difference.  therefore, you will not catch very
  important errors if you use the naive approach to Scheme.  (no, I'm not
  talking in the "standards purist" mode -- Scheme is deliberately designed
  this way, and second-guessing designers is a Bad Thing.  of course, it
  was a gross and very annoying mistake, but the designers should fix that,
  not users.)

| I was under the impression that Scheme was a dialect of Lisp.  From what
| you say, Scmeme is a whole other language (like JavaScript isn't Java).

  Scheme is not a dialect of Common Lisp.  the common heritage, if any, is
  so old and so far removed from today's reality that we're almost talking
  about a missing link.  Scheme owes more to Algol than to Lisp, in my
  view, just like Java owes more to Smalltalk than to C++.  the syntactic
  similarity is irrelevant for meaningful comparisons.  Scheme adherents
  want to tell you Scheme is a dialect of Lisp, but I don't get it.  what
  do _they_ get from confusing people like that?  is it a hope for a piece
  of the market that Common Lisp has created?  some Lispers (well, at least
  one, but he's also a Schemer) will insist very strongly that Common Lisp
  is not the only Lisp to consider.  the only merit of this latter attitude
  is that it makes the Scheme wish come true, but there aren't as many
  Lisps as there used to be 10-15 years ago.  if you spend your time
  learning any other Lisp these days, I'd say you're wasting your time
  unless, of course, the Lisp is an embedded Lisp in some product you need
  to use.  (this includes the sadly deficient Emacs Lisp.)

| This brings up another question.  It seems that Lisp is not case
| sensitive.

  well, I can't speak for "Lisp" in the sense that it is something that
  Scheme is (also) a dialect of, but Common Lisp is certainly case
  sensitive.  symbols in the COMMON-LISP package are all uppercase, but you
  would normally set *PRINT-CASE* to :DOWNCASE and (readtable-case
  *readtable*) to :UPCASE, so you could read and write them in lowercase.
  both |lowercase| and \l\o\w\e\r\c\a\s\e all have lowercase symbol names,
  so it's not like you cannot get it.  also, to maintain backward
  compatibility, you can set the readtable-case to :INVERT, which upcases
  all-lowercase symbol names and downcases all-uppercase symbol names (not
  counting characters escaped with | or \).

| How many people would be upset if a Lisp implementation came out that was
| case sensitive?

  if you make the reader preserve case, many would object to having to
  write symbol names in all uppercase.  if you invert the case of all the
  symbol names, you create a new dialect that doesn't talk to other Common
  Lisp implementations.  amazingly, there is no standard function to do
  case conversion the way the symbol reader and printer does it, so you
  have to call out to the reader or printer to get that behavior.

  case is a personal preference in my view, and Common Lisp has done the
  right thing in allowing each programmer the ability to choose his own
  style.  and it's not like it's a hard thing to change.

| It sure makes string comparison easier.

  what does?  case sensitivity or case insensitivity?  I think the latter
  is strongly preferable when dealing with protocol or user input.  btw,
  STRING= is case sensitive, while STRING-EQUAL is case insensitive.

Anyway, what I started out to say was that (as anyone who's done
prioritization of bug reports knows), "frequency" of problems (and
consequently of pain felt and reported by users) is a
multi-dimensional quantity.  Saying that something happens "a lot"
doesn't make clear what axis of this multi-dimensional quantity you're
saying has a high magnitude.  For example, I was once at Symbolics
when just before a major release, I found a bug in special binding of
lambda variables in a lambda combination (not just a lambda
expression; in an actual ((lambda ...)...).  "It's all packaged and
ready to ship," someone protested. "How frequently does the bug
happen?"  What was I to answer?  Every time anyone runs my code, I
told them.  But then, I don't know how often they do that.  Nor do I
know how many developers are like me.  So at minimum frequency is "how
often is code developed which exercises a given bug" along one axis vs
"how often is code containing the buggy code executed" along another
axsis vs "how often in the buggy code that's being executed is the
path reached which tickles the bug".  Maybe there are even more axes.
In the case in question, it just seemed embarrassing to have lambda
broken when you're a lisp machine company, so Symbolics fixed it.  But
oddly enough, hardly anyone then or now used lambda combinations at
all, even though they're retained in the language.  Most people use
LET instead.  And of those, VERY few use specials in the binding
list because it's mostly classical programmers and scheme programmers
who like lambda combinations, and they all hate specials.  So really
the bug was not likely to occur at all.  Except when it did.  And
then always.  So it goes.

Why does all this matter?  Well, I guess I'm just trying to point out
that while what Barry said is probably true--that it probably hasn't
materially hurt Franz's implementation in the market, it doesn't follow
that it doesn't cause individuals grief.  I bet it probably has, though
I have no stats to back me up.   And I just feel a little bad for
the people who do get hit by this that they ALSO find people implying
it's a matter of no consequence.   To the people it happens to, it is
of consequence.  Whether it's of consequence to the world that it's of
consequence to these people--well, there's an open question.

Emacs on the other hand is another story.  Emacs is not part of any
standard and since the design choice is entirely arbitrary, I
absolutely agree with Barry that it can't hurt really either way.
The important thing is just that it's defined.

The problem in the CL case is that it's defined a certain way and
(to my understanding) Franz doesn't follow the standard.

  well, they do now.  although it doesn't appear they have forgiven me
  completely for all the noise I made about it, ACL 5.0 does come with a
  very significantly improved symbol reader and printer -- they both now
  respect every relevant printer variable and print-read consistency is
  maintained in all cases, which was not the case previously.  I rolled my
  own symbol reader and printer for ACL 4.3 because I got sufficiently
  annoyed by the broken implementation then, but I'm happy to say that
  that's history.

  src.naggum.no/lisp/symbol-printer.cl (HTTP or FTP) has the code for ACL
  4.3+, if anyone's interested.  it's _very_ heavily optimized.

As to Allegro, I've heard tell it uses lowercase symbol names, which
would be a potential cause of portability problems, but I have no way
of confirming this because I don't have access to your/Franz's
products.  If you'd like to correct my notion (and set the record
generally straight for others), I'd certainly welcome that.  I'd
rather work with accurate info.

Of course, as I thought I (perhaps clumsily) mentioned, my prior
remarks were not aimed at Franz at all even though it was them I was
using as an example.  It was just the example I (perhaps mistakenly)
thought was on the table when I went to react to and extend the
other comments on the subject.\

Others have already clarified that I was not referring to Allegro CL when I
said Franz Lisp (Kent, did you really think that *I* would be so
imprecise?).

Even if Common Lisp were the only important Lisp today, there would
still be Lisp's history.  Lisp, like Madonna, turns 40 this year.
(I'm assuming the anniversary conference is in the right year
rather than properly checking, though).

The phrase "dialect of Lisp" has been used for many years, and
"dialect of Lisp" was taken to be a fairly broad category.
It was natural to speak of Scheme as a dialect of Lisp, and
one even finds sub-varieties of Scheme (such as T) referred
to as "dialects of Lisp".

That's the way people in the Lisp world talked (and they still do,
though not quite so much as before).  What did they mean by "dialect
of Lisp"?  One way to find out is to look at how that phrase was used
and hence at what things were said to be dialects of Lisp.  If we do
that, then it seems pretty clear that, as a matter of usage, Scheme is
a "dialect of Lisp".

But that way to talking about Lisp can mislead, and it even
became somewhat dangerous once standardisation began, because
some people claimed Lisp was just one language (albeit with
dialects) and so should have only one standard.

The US position in the ISO WG was that Lisp was a family of
languages, and I believe that position was correct.  And so
(the argument went) there should not be a standard for "Lisp"
but only for specific Lisp-family languages.  John McCarthy
said he would denounce any standard for "Lisp".

An observation that goes back to at least the 70s is that
so-called dialects of Lisp could be as different from each other
as different languages in (say) the Algol family.  That's one
reason why "dialect of Lisp" can mislead.  Another problem
with "dialect" is that dialects tend not to be taken as
seriously as languages, as in the quote about a language
being a dialect with an army.

So, all things considered, the "dialect of Lisp" way of talking
is probably more trouble than it's worth.

  but what _is_ the Lisp that both Scheme and Common Lisp are dialects of?
  if there is no such thing (and I don't think there is, anymore, although
  there might well have been in the distant past), then it is not useful to
  talk about it.  "dialect" is not a mark of independent quality in my view
  and there's a weird interaction between "dialect of Lisp" and the effect
  the mark has on various languages that claim it: one language may try to
  capitalize on the work of another ("we're _all_ dialects"), yet it may be
  used to reduce the value of the work of another at the same time ("we're
  all _merely_ dialects").

* Erik Naggum <e...@naggum.no>
| some Lispers (well, at least one, but he's also a Schemer) will insist
| very strongly that Common Lisp is not the only Lisp to consider.

* Jeff Dalton <j...@gairsay.aiai.ed.ac.uk>
| Well, I'll certainly insist that Common Lisp is not the only Lisp.

  the two words "to consider" is essential to what I wrote above.  I know
  that you go ballistic every time somebody forgets to mention the myriads
  of other Lisps that you want us to remember, and that's why I attempted
  to be very specific.  I'm annoyed that you appear to continue unimpeded
  with your standard rhetoric.

| So, all things considered, the "dialect of Lisp" way of talking is
| probably more trouble than it's worth.

  I agree, including your argumentation.

So I'm rather bemused by all this fuss.

I remember that there was a debate at one of the first Lisp Users and
Vendors conferences (perhaps the first one after the Symbolics Lisp Users
Group morphed into the Association of Lisp Users) about whether Dylan
should be considered a dialect of Lisp, even though they were abandoning
parentheses.

Not that anyone likely cares, but Perl (Perl 5, in particular, since almost
everything is first-class) comes pretty close to being a dialect of Lisp,
IMHO.

  that's pretty amusing, considering Larry Wall's explicit hatred for Lisp.

  assuming this was as rhetorical as it seems, why is "the King's/Queen's
  [British] English" the _obviously_ wrong answer?

| If you don't like the "dialect of X" terminology, then perhaps "member of
| the X family" would be better, but in my mind they mean the same thing.

  it seems to mean the same thing only when X = Lisp.  otherwise, it makes
  no sense at all to claim they are the same.  English is not a dialect of
  Germanic, but it is a member of the Germanic language family.  neither is
  English a dialect of Indo-European.

Although most of them were probably influenced by Lisp (especially Scheme),
I think they have gone a far way from being in the Lisp family, with their
static higher-order typing systems, lazy-evaluation, Monadic I/O systems,
even higher-order module systems.

I think the real family-membership-test of any language family is
looking at source-code produced for real-live programs in them.  If
you find a large overlap in idioms, then either the programmer was
programming "Fortran in Lisp"(TM), or the languages are indeed members
of the same language family.

Regs, Pierre.

Footnotes:
[1]  Remember also that Dylan at first _had_ prefix-syntax, and only
later on adopted a second, infix-like syntax, which was then adopted
as the primary, and finally only syntax.  But semantically, Dylan is
very nearly a "streamlined" CLOS, with integration of type/class
hierarchy, and a number of annotation possibilities to simplify the
compilers task of optimizing the whole thing ;)  (WARNING:
Oversimplification Alert!)  But in giving up on prefix-syntax, Dylan
has gone a step too far for me ;)

I think that the discovery that the Perl, Dylan, and Java folks hit on is
that if you can get around many people's irrational bias against Lisp's
heavily parenthesized syntax, they actually like most of the remaining
features, which just make programming easier.  Garbage collection was
probably just one of the many language features that has simply been
waiting for machine speeds to catch up -- none of the current generation of
new programmers remember the days when Lisp would hang for a minute or more
in GC, so they're not biased against this and enjoy not having to call
free().  I recall that when C++ first started gaining popularity, one of
the most frequent Usenet posts in its newsgroup was "where can I get a
class that implements garbage collection?", and soon classes that implement
reference counting or conservative GC were popping up right and left.
Similarly, draft ANSI C++'s STL is in the spirit of Common Lisp's sequence
functions, but goes even further in providing higher level data structures
(stacks, queues, sorted tables, etc.).

(If they are, indeed, considered dialects -- I have not checked this.)

I would have thought that a language was an abstraction relative to
its dialects.  All speakers would speak one dialect or another, even
if one dialect was considered more standard than the others.

In any case, I am not saying that "dialects of Lisp" is the right
way to describe these things, only that it is established usage.
One can still criticise it as using "dialect" in a nonstandard way,
if that's the case, or whatever.  But if someone says "___ is a
dialect of Lisp", and we want to know whether they've said something
true or false, we need to understand how they were using "dialect of
Lisp".

At the same time, if we take "dialect of <language>" in a probably
more standard sense, then these languages are not "dialects of Lisp".
As many have noted for at least 20 years now, these so-called dialects
can be as different from each other as the things that are described
as different languages in, say, the Algol family; and the "different
languages" way of talking is at least less misleading (in addition to
whatever other advantages it might have).

Anyway, Saying that Lisp is a family of languages has a number of
advantages over talking of "dialects of Lisp", and members of a
family can be very different from each other.

The other alternative that sometimes occurs is to use "Lisp" to mean
only Common Lisp.  I don't see anything wrong with that in contexts
where it will not be misunderstood: where it's clear that it's being
used just as a shorter way to refer to Common Lisp.

But I think it's a mistake to use "Lisp" in that way when it may be
misundrstood as referring to all of Lisp.  This matters especially
when "Lisp" is being criticised, as it all too often is.  It's fairly
common for people to say that "Lisp" is a too large a language, or
makes it too hard to deliver small applications, or has various other
problems.  But often these claims are not true of Lisp in general
(some Lisps are very small languages, a Lisp could make it easy to
deliver small applications, and so on), but only of certain particular
Lisps (maybe Common Lisp), or only of certain implementations.

Another case where I disagree is where someone seems to go further
than using "Lisp" as conveniently short for "Common Lisp" and say that
Common Lisp is the only Lisp, or that "Lisp" just *means* common Lisp
(and hence that there's either no Lisp family or else no other
member).

For in fact other Lisps do exist, a number of them are still being
used, and Lisps can be significantly different from Common Lisp.