B.S.

[Guy.Steele at CMU-10A]

Maybe infix syntax *is* easier to read -- it is certainly more concise --
when there are no more than a couple of dozen functions involved, and
none takes more than two arguments, and there are enough symbols to go
around.  Indeed, there are not enough ASCII characters to go arond
even for the common operators, so PASCAL must use the abomination "<>"
for "not equals".  (Why an abomination?  Because for some of the types
in PASCAL to which "<>" applies, the concept of "not equal" is not the
same as the idea of "< or >"!  Sets are an example.)  Similarly FORTRAN
uses ".AND.", ".LE.", and so on.

When you have an extensible language, however, such as LISP is, one
quickly runs out of meaningful symbols.  I have had some experience with
a LISP-like language with a user-extensible ALGOL-like syntax, namely
EL1 at Harvard.  Maybe you can tell what A * X + C > Z is supposed to
mean, but how about A @> B <= C <==> D ?  Could you really remember the
precedences of ten new operators just defined on the preceding two
pages of a program you were reading?  Probably not.  And you have to have
precedence rules of some sort; otherwise everything must be
parenthesized anyway anyway, and you lose the advantage of infix over
prefix.  Can you even remember the nine precedence levels of PL/I?
That's why APL, which doesn't even let the user define special symbols,
has no relative precedences, but only a uniform right-to-left parsing rule.

When you have functions of more than two arguments, infix syntax breaks down,
and you have to use prefix after all in most algebraic languages.  (In APL
you simply are not permitted to have functions of more than two arguments!)

In closing, let me quote two more experienced people than I.  McCarthy,
in his paper on the history of LISP for the ACM History of Programming
Languages Conference, explains that LISP was intended to have an
infix-style syntax for programs, the parenthesized format being used
only for data.  A data parser (READ) was written to accompany other
system functions such as CONS and ASSOC.  It was only then that it was
realized a universal interpreter (EVAL) could be written which would
treat data objects as programs.  This was much easier to code than the
program parser, and once it existed it caught on and no one ever got
around to writing the infix parser.  Moreover, McCarthy speculates that
this very accident was one of the important reasons for the persistence
of LISP for twenty years, because it made it so much easier to realize
that programs and data could be intermingled, which is of great
importance in many LISP applications, expecially in AI.

The second quote:  at the APL '79 conference, Alan Perlis, a great fan
of APL, got up to speak on the differences between LISP and APL.  The
conclusion of his talk was as follows (I paraphrase):  "There are two
lessons APL must learn from LISP to thrive.  (1) Functions must become
manipulable data objects of the language.  (2) We have to get rid of the
crappy infix syntax!"

--Guy