Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!hplabs!otter.hpl.hp.com!otter!sfk
From: sfk@otter.hpl.hp.com (Steve Knight)
Newsgroups: comp.lang.lisp
Subject: Re: Re: extension languages can be darn small, yet still powerfull
Message-ID: <1350028@otter.hpl.hp.com>
Date: 27 Aug 90 10:31:11 GMT
References: <1990Aug26.205018.18067@cbnewsc.att.com>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 74

With trepidation, I'd like to try to make a couple of points about Lisp
syntax.  The basic point is that the virtues claimed for Lisp syntax
are not exclusive to Lisp. 

Lawrence writes:
> Simplicity is nice, but extensibility is the much more important
> virtue of Lisp syntax.  

I agree with this.  However, there's no reason to think that extensible
languages are obliged to adopt the approach of Lisp and Prolog in which
the programmatic syntax is identical to that of some concrete data types.
The main advantage with the Lisp/Prology approach, as I see it, is that
the learning curve for extension-programming is shortend.  However, here's
an alternative look.

It is quite easy to imagine a programming language with (say) an Algol-like
syntax in which the parse tree is available as a standard data-structure.
Extending the language has several solutions.  The elegant solution might
be to create new grammar rules with associated rewrite actions.  A more
brute-force approach, used in Pop11 (a Lisp derivative), is to supply the
compiler's parsing & tokenising procedures.

The advantage I see in this approach is two-fold.  Firstly, the programmer
gets to deal with a more familiar kind of syntax.  Secondly, the parse
tree can be made more regular, making extension programming easier.

Speaking personally, I am no fan of the Lisp or Prolog style of syntax.
It seems to me to be an unfortunate conflation of issues -- external 
syntax is there to make programs readable etc -- internal structure is
there to make manipulation of programs convenient.  I think that Prolog
makes the better job of it, having the advantage of being relational so
that quoting rules aren't required, and providing a good infix/prefix/
postfix operator system.  I should point out that I've happily 
programmed in both of these languages for quite a few years and am
very comfortable programming with them.  But I don't think that they are
beyond improvement.

Lawrence continues:
> I have found that those who "hate" Lisp syntax almost invariably have
> never used a powerful Lisp development environment such as Symbolics
> Genera, or even Harlequin's LispWorks. 

Cause and effect -- but which way round do you think it operates?  We
have a Symbolics with Genera sitting around turned off.  We used it for
a couple of projects but the incremental benefits were too small.
I agree with Lawrence in
thinking that many folks pre-judge on the basis of ignorance, it would be 
odd if it wasn't true!  However, the issue of Lisp's syntax is largely
independent of programming environment -- you don't need Lisp's syntax
to do sensible things with programs.  

I am inclined to think that the best interpretation of Lawrence's
observation is that expensive Lisp equipment is of much more interest to
folks who are prepared to tolerate the problems with Lisp.  And I would
count the syntax as, overall, a problem because the benefits could be
achieved without the cost.

> Indeed, the "haters" usually
> have never used any Lisp system beyond the 1962-vintage Lisp 1.5 that
> most of us oldsters were introduced to in undergraduate school.

That doesn't ring a bell with me.  My (UK based) experience is that people's
exposure is to Lisp's such as Lucid.  This doesn't really sweeten
the experience, to be fair, since so many commercial lisp systems have
intense memory requirements -- which ends up spoiling the experience.

Another factor in the development of attitudes hostile to Lisp, in my view,
is the bias of university teaching.  (I'm only talking about the UK here.)
I've had a great deal of trouble getting UK graduates to accept Lisp
as a viable language -- even for prototyping.  The presentation of Prolog
is much fairer, although I encounter very set attitudes about what can
be done with Prolog.  

Steve "Just the opinions, ma'am" Knight