Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!cs.utexas.edu!asuvax!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: scheme [Re: What does an anti-perl look like]
Message-ID: <4736@optima.cs.arizona.edu>
Date: 30 Jun 91 22:30:39 GMT
Sender: news@cs.arizona.edu
Lines: 87

In article  <Jun.30.04.42.26.1991.22172@paul.rutgers.edu> Silver writes:
]My opinions on this discussion highly favor the all-is-data, syntax-is-simple,
]memory-is-managed, ... languages.

These three things are mostly orthogonal.  The only dependency is that
it is pretty hard to have an all-is-data model without memory
managment -- otherwise those features are independent and unrelated.

]Make the distinction between SYNTAX and SEMANTICS.

If you have a wierd syntax that encourages structures with wierd
semantics (like a mulitple-argument minus), then the syntax is making
the semantics more complicated and you have to take that into account
when discussing if the syntax makes the language simpler.

]The semantics of the special forms can then be described in a straightforward
]fashion, for example, by noting the equivalence of the following:

That doesn't make the syntax any simpler.  You still have to describe
all the possible variations of all the special forms.

]I tend to agree with you that the SEMANTICS of some `do's are much too hairy,
]so I never use it.  Nonetheless, this degenerate case works the same as the
]others, just a matter of degree.

I guess it depends on what you are going to call syntax (the
distinction is not as obvious as you seem to think).  I include in the
syntax the positioning of the relevant parts according to their
function.  If you are going to claim that syntax is just what is
describe by the BNF grammar then I say that there is no reason to
suppose that such simplicity is an advantage.  Who cares if you can
describe lisp syntax as a sequence of s-expressions?  That doesn't
tell you anything about how to write a lisp program.

]>> 3. It's flexible, in the way that (say) infix isn't.  Most of the basic
]>>    operations (+, *, and so on) naturally extend to any number of arguments
]> A very minor advantage, and probably the only real one.
]The ability to handle variable numbers of arguments is a big win.  Seriously
]affects readability and usability.  This feature should be provided by a clean
](hell, transparant) syntax.

I don't believe (+ x1 x2 ... xn) is any clearer than x1 + x2 + ... +
xn.  Hmm.  I think I'm going to have to take back where I said that
this is an advantage of lisp.  I was really thinking about the ability
to distribute an operation over a sequence, which is unrelated to
syntax.

]YOU can insert the parens, but the next bloke might not.  And you may have to
]play with his code someday.  And when you do, you better remember that C's
]bitwise-and operator `&' is of higher precedence than the bitwise-xor operator
]`^'.  The regular syntax eliminates this type of error even if I'm not fond of
]expressiong *every* expression in prefix notation.

If you don't remember the precedence then look it up and put in the
parens.  Or have an editor do it for you.  It was lisp defenders who
set the precedent that if an editor function can make up for a
deficiency then the deficiency doesn't count.

]Note that I've conveniently sidestepped the issue.  Because programs are data,
]I know that I can write an infix expression macro within the bounds of the
]language.

Terrific.  Then I'll get an infix language with programs-as-data and
do the reverse.  It doesn't prove anything either way.  (Except that
the fact that people always want such things in lisp and never want it
in prolog implies that prolog has better syntax).

][teaching languages]
]I've invariably gotten faster results with Lisp than with imperative
]languages like C and Pascal.  The major issue was one of syntax.
]Once we struggled through a formal discussion of the general syntax
]and the low-level semantics, they had no problem learning the
]individual special forms.

It sounds like you are agreeing with me that syntax is the major
problem in getting people to accept lisp.  It is obvious to me that
except for the syntax, it is _much_ easier to program in lisp than in
C or Pascal.  If lisp had a decent syntax it would be that much better
a language.

(Just to nit-pick, Lisp _is_ an imperative language.  It happens to be
expression-based and to have first-class functions and lots of
built-in functionals, but it also has a global store and assignment.)
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman