Subject: From: AIList Moderator Kenneth Laws <AIList-REQUEST@SRI-AI>

From: [email-masked]
Date: Mon, 8 Jul 85 18:25:52 edt

Received: from sri-ai.arpa by csnet-relay.arpa id aa00309; 7 Jul 85 20:16 EDT
Date: Sun  7 Jul 1985 16:28-PDT
Reply-to: AIList@SRI-AI
US-Mail: SRI Int., 333 Ravenswood Ave., Menlo Park, CA  94025
Phone: (415) 859-6467
Subject: AIList Digest   V3 #89
To: AIList@SRI-AI
Received: from rand-relay by vpi; Sun, 7 Jul 85 21:26 EST

AIList Digest             Monday, 8 Jul 1985       Volume 3 : Issue 89

Today's Topics:
  AI Tools - Lisp vs. C & Interlisp Comments

----------------------------------------------------------------------

Date: Wed, 3 Jul 1985  15:30 EDT
From: "Scott E. Fahlman" <[email-masked]>
Subject: Lisp vs. C

I won't try to take issue with Richard Jennings's views on Lisp vs. C,
except to note that he is only in a position to compare one dialect of
Lisp (XLISP) to one dialect of C on some sort of MS-DOS machine --
presumably a tiny one -- for one particular kind of task with one
particular virgin programmer who had been trained in in a different way
on the two languages.  His observations are probably valid for this
case, but I wouldn't draw any sweeping generalizations from this.

Lisp really requires a full-fledged environment in order to be an
attractive language.  A lot of people got turned off very badly back in
the bad old days when the Lisp environment was primitive and the address
space of most machines was too small to hold the kinds of features that
we see today on the various Lisp machines.  Now we are seeing the same
"turn off" among people whose exposure to Lisp consists only of using
very small Lisps on machines with only, say, 512K bytes of memory.  On
such a machine, a language like C (which evolved to fit the PDP-11, a
machine whose address space is even smaller) probably is superior for
getting real work done.  This phase will pass just as soon as machines
with adequate virtual memory systems become as common as PC's are today.

-- Scott Fahlman

------------------------------

Date: Wed 3 Jul 85 13:55:02-PDT
From: Christopher Schmidt <[email-masked]>
Subject: ~= re: Interlisp comments

         [Forwarded from the Stanford bboard by Laws@SRI-AI.]

    [...] Unfortunately at least once programming system I know of
    (Interlisp) actively discourages this by making it painful to put
    comments in programs.  For this reason alone Interlisp disqualifies
    itself as a serious programming environment.

Isn't that a little like saying that Boeing, by having tiny restrooms
disqualifies itself as a serious airplane manufacturer?

    I didn't say that comments are impossible in Interlisp -- merely that
    it's painful to put them in.

Pain is subjective.  For my money, tracking down bogus indentation, missing
semicolons or unbalanced parentheses or misspelled symbols in a
text-editor-oriented language is ever so much more painful than commenting
Interlisp.

All of these problems associated with the syntactic sugar of most
programming languages are non-issues in Interlisp, where the interned
form is edited.  For the non-Interlisper it should be explained that
in DEdit (the Interlisp-D display structure editor) the programmer
selects S-expressions with the mouse and operates on them through a menu.
Note that the user selects S-expressions; not the textual representation
of an S-expression.  Eg., a user can't select a parenthesis because it
is only an artifact of the pretty-printer.  Since parentheses are generated
only by the pretty-printer on redisplaying a transformed S-expression,
they can never be unbalanced.  Since atoms are typically "typed" into a
program by buttoning an existing instance and using a menu command which
copies the interned pointer (not the characters of the PNAME) spelling
errors can't occur.  Similarly, indenting is the job of the pretty printer--
not the programmer--and is done per-window, so editing windows may be of
different sizes.  I am amused to see CADR-sized editor windows on 3600's.

    For the edification of those who have not had the privilege of being
    subjected to Interlisp's slavish adherence to the principle that it
    should constitute an entire programming environment (as opposed to
    being just another programming language living on a general purpose
    computer system), one of the concomitant requirements of this philosophy
    is that all operations, including editing, be done on Lisp objects.

Some of us are willing slaves.

    This means that comments (which are handled by a function called *
    that does not evaluate its arguments) are a part of the running program.
    Thus, extreme care is required in the placement of comments.  [...]

Extreme care must be taken when spelling identifiers in C programs and placing
semicolons and parentheses.  Nobody said programming would be safe!  <:-)

    [...] In fact, because Lisp is largely a functional language, there
    are relatively few safe places to put comments.

I don't think that it is unfair to ask a programmer to learn the semantics
of the programming language he is using.  Given an understanding of PROGN,
COND, AND, OR, and the interpreter, I don't think it is difficult to comment
Interlisp programs at all.  Anyway, the compiler catches instances where
the programmer has used a comment for its value and warns him with a message
like "Warning: value of comment used".  Actually, I haven't seen this message
in a year or two.  When was the last time cc barfed on a semicolon you forgot?

    [...] Similarly, in the display editor on Interlisp-D, comments are
    kept as far away from the executable code as possible (on the same
    line) and displayed in a font which is considerably less readable than
    that used for non-comments.

You have only to rebind COMMENTFONT to a larger/bolder fontclass if you
don't like the default.  What font does EMACS use for comments in C programs?

    This is the basis on which I justify my earlier claim that Interlisp
    "discourages" comments, which I consider an undesirable goal.

As I've said too many ways above, I don't think Interlisp discourages
misplaced comments any more than C discourages misplaced semicolons.

--Christopher Schmidt

------------------------------

Date: Sat 6 Jul 85 00:01:40-PDT
From: Peter Karp <[email-masked]>
Subject: Interlisp comments

         [Forwarded from the Stanford bboard by Laws@SRI-AI.]

The Interlisp manual contains roughly 25 chapters which average
approximately 25 pages each.  These are big pages with closely
packed type.  The Interlisp environment has been evolving for
almost 20 years.  This should suggest to you that it is a rich
and complex entity.

Are we really expected to take seriously the proposition that
we shouldn't use this language because it doesn't let you put
comments anywhere you please?  [...]

------------------------------

Date: Fri 5 Jul 85 16:24:29-PDT
From: Christopher Schmidt <[email-masked]>
Subject: ~= re: Interlisp comments

         [Forwarded from the Stanford bboard by Laws@SRI-AI.]

[...]

    We're not talking about syntactic sugar or ease of use. We're talking
    about a limitation on the functionality of the programming environment.

My mistake then.  I think that C comments are the epitome of syntactic sugar;
discarded by the cc parser as if they never existed.  And rather than
Interlisp's being a programming environment that "holds comments in contempt"
I would go so far as to claim that it gives them MORE respect than
unix/EMACS/C.  In the unix/EMACS/C environment let's say that we have an
error.  unix gives us one of the many helpful error messages from the set
{bus error core dumped | segmentation error core dumped}.  The user invokes
the break package (cdb) (by hand).  Where are the comments now?  Where is
the symbol table?  The hacker only gets that if he is lucky!  In Interlisp,
by contrast, one of >50 error messages is printed, a break package window
opens up, a stack trace opens up (any frame can be selected and inspected
symbolically in its own window), and a menu of break package commands is
available (in addition to the entire programming language).  If one invokes
the editor from the break package (picking the function from the stack trace
with the mouse), the source code is right there; the variables can be
evaluated in the stack context of the break; and the comments are still
there!  I call that esteem, not contempt.  Now an Interlisp break is not
a post mortem.  Within the break package one can change the variable; rewrite
a function if desired and continue the program with the new definition,
which is now THE definition.  Do fixes made in cdb get incorporated into
the original source automatically?

[...]

--Christopher

------------------------------

Date: Fri 5 Jul 85 18:01:35-PDT
From: Wade Hennessey <[email-masked]>
Subject: interlisp comments

         [Forwarded from the Stanford bboard by Laws@SRI-AI.]

Chris' comments about the ease of debugging in INTERLISP are true of any
lisp system. They are not really relevant to greep's dislike of INTERLISP
or liking of UNIX. For example, ZETALISP uses a commenting style
similar to C, and yet it provides the same debugging functionality
of INTERLISP. There are several useful functions in ZETALISP which get
the system to find the source file where a function is defined, and then let
you start editing/examining the definition, comments and all. Thus, you
needn't make comments part of the code to make them easily accessible at
all times.

Wade

------------------------------

End of AIList Digest
********************