Subject: Re: I don't understand Lisp
From: Erik Naggum <clerik@naggum.no>
Date: 1998/09/14
Newsgroups: comp.lang.lisp
Message-ID: <3114753392163854@naggum.no>

* trashcan@david-steuber.com (David Steuber "The Interloper")
| Does this mean that while CL can read CL and eval it, Scheme can not
| read Scheme and eval it?

  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.

#:Erik
-- 
  http://www.naggum.no/spam.html is about my spam protection scheme and how
  to guarantee that you reach me.  in brief: if you reply to a news article
  of mine, be sure to include an In-Reply-To or References header with the
  message-ID of that message in it.  otherwise, you need to read that page.