Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: jonl%kuwait@lucid.COM (Jon L White)
Newsgroups: comp.lang.scheme
Subject: To Lisp, or not to Lisp; that is the question.
Message-ID: <9103120750.AA00865@kuwait>
Date: 12 Mar 91 07:50:36 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 98

In   Volume 3 : Issue 154   both Arun Welch and Jeff Dalton jump to
the defense of certain Lisp aspects as being "hard core" rather than
simply "soft" environmental decoration.  Both of these were in response
to Ken Dickey's minor criticism in    Volume 3 : Issue 153  in which
he separates out the "incremental" nature of Lisp from the language
definition proper.

First, let me say that I wholeheartedly agree with Arun and Jeff; but
their rebuttal is not so much a refutation of Ken's comments as the
other side of a coin.  As Ken himself said "... Jon's points are well 
taken (`Lisp' is not just a family of languages but a way of `doing 
business')."  Part of that "way of doing business" has been an explicit 
catering to the prototyping developer; but another part has been the 
mathematical reflective nature of languages.  See for example Brian 
Smith's work on 3-Lisp.

Here are the kinds of comments I would have made on this topic, and in 
fact did make privately on another channel:

  This is a very delicate question; I claim that there is no easily
  productive boundary between these concepts and "the language".  True,
  there are some things that haven't yet become part of the Lisp
  language that are truly "environmental" -- I would limit these to
  the OperatingSystem type things that other languages have to interface
  to also, such as file path names, the file system in general, X, 
  "windows", GUI's and persistent object stores and so on.

  But is APPEND part of the language of Lisp, or is it merely an
  electable function in the environment?  How about PRINTF and FSCANF
  for C?  The reason I think that the answers for C are easier and
  clearer is that Lisp, in constrast to C, is a highly reflective
  language; the compiler and loader are "first-class" and resident
  from the viewpoint of a "typical" Lisp programmer, and this shapes
  one's attitude of what is "in" the language very much.  Again, it
  is still Lisp, in my opinion, if you elect to leave the compiler 
  out etc.; but it just ain't C if you throw these things into C
  (i.e., it is UNIX, or "Some Wonderful C debugging environment", 
  or ..., but it is not what has come to be known as C.)

  Thus the "interactive" versions of C and Fortran are not even billed 
  that way -- they are the addition of an interactive debugging
  environment to a kernel C or Fortran language.  And perhaps that
  is why one is tempted to think of such features as being merely
  an "environmental add-on" for Lisp rather than as a fundamental
  reflective feature.

In addition to these comments, one must recall that for years the
obstinate barrier to porting C applications from one vendor's Unix
to another's has been the clear lack of standards in what has come
to be called the "runtime library".  Is the "runtime library" merely
an environmental issue?  I would say no; and no good purpose can be 
served by excluding these items from a standardization process simply 
because they fall outside a "hard core" kernel language definition.
Recall Dalton's concern that classifying too many important parts
of a language/world as environment drastically reduces portability.


Finally, recall that Common Lisp's fate has been forever altered in a 
significant way by the adoption of CLOS.  Fewer places could make the 
reflexive nature of Lisp more evident than the so-called Metaobject 
Protocol (or, the emerging proposals for a standard such protocol).  
CLOS written in CLOS is not just a metaphor now, but an essential 
language necessity.  We of the community that foisted this humongous 
system onto the Lisp world (Common Lisp world), did not do so just 
for the idle intellectual curiosity of a reflexive language with a 
metacircular definition, but rather we did it because of the history 
in the Lisp world of wanting to "tailor" the system-defined facilities 
(or, the standardized environment???) in an application dependent way.
Finally, now, we have a reasoned and principled way to permit such 
"tailoring" without adding a 1001 ad-hoc "hooks".

As a "way of doing business", Lisp is definitely more meta.


-- JonL --



P.S. Ken's message referred to me as "Jon"; my full name is John L. White,
     but everyone refers to me as JonL (pronounced "John-ell").  There is
     another famous John R. White in the world of computer languages, and
     confusingly enough, during 1983-1985 when we both worked at XeroxPARC,
     we had offices within 50 feet of each other.  I don't actually know
     if anyone refers to him as "John R".


P.P.S. Someone mentioned to me privately that  SML (Standard ML of new 
       jersey?) and Modula-3 are statically-typed languages with Garbage 
       collection.  Right.  My original message was referring to 
       "conventional" computer languages, and alas not even APL nor 
       SmallTalk fall into that blessed category (and they have had true 
       garbage collection just about as long as Lisp has.)  I also know 
       of a research group at UmassAmherst that is putting GC into a
       strongly-typed "conventional-looking" language, and there is a
       sense in which Modula is "conventional-looking";  More power
       to them!   Reports of "heuristic" GC for C++ have been confirmed
       (by published research);  reports of "accurate" GC, however, are 
       premature.