Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!aramis.rutgers.edu!paul.rutgers.edu!gaynor
From: gaynor@paul.rutgers.edu (Silver)
Newsgroups: comp.lang.misc
Subject: Re: scheme [Re: What does an anti-perl look like]
Message-ID: <Jun.30.04.42.26.1991.22172@paul.rutgers.edu>
Date: 30 Jun 91 08:42:27 GMT
References: <4671@optima.cs.arizona.edu>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 80

My opinions on this discussion highly favor the all-is-data, syntax-is-simple,
memory-is-managed, ... languages.

gudeman@cs.arizona.edu writes:
>> 1. It's simple.  You can summarize all the syntax you need to know on the
>>    back of a postcard.
>
> Not true.  You have to specify the special syntax of defun, let,
> protect-unwind, do (which is worse than anything I have ever seen in an
> algol-like language), etc.  You have to specify what operators take more than
> the normal number of parameters.  And for non-associative operations you have
> to specify what multiple parameters mean.  Lisp syntax is _not_ trivial.

Make the distinction between SYNTAX and SEMANTICS.  In a description of Lisp's
semantics, one should introduce the notions of macros and read-time evaluation.
The semantics of the special forms can then be described in a straightforward
fashion, for example, by noting the equivalence of the following:

    (let ((variable-1 value-1)     ((lambda (variabl-1 ... variable-N)
          ...                         form-1
          (variable-N value-N))       ...
      form-1                          form-M)
      ...                            value-1
      form-M)                        ...
                                     value-N)

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.

>> 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.

>> 4. You don't have to worry about any precedence rules whatsoever.
>
> The same is true of infix syntax.  If you don't know the precedence you can
> always use parens (and the result is no worse than lisp).  The difference is
> that with infix syntax you have the choice.

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.

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.  Experience has shown it to be relatively straightforward.  (However,
I never use the critter because I am comfortable with prefix notation.)
Extending this toy to handle new operators with a given precedence and
associativity is relatively easy.  In fact, I'd say that it does infix better
than most imperative languages because it is so easy to manipulate programs as
data in Lisp.

>> You're the one making the positive assertion, that Lisp's syntax is a
>> hindrance to learning it.  You're the one who has to provide the evidence.
>
> The fact is that you seem to believe that lisp syntax does not cause
> problems.  This is a real opinion.  It is different from having no opinion on
> the matter, and is just as subject to the need for evidence as is the
> opposite opinion.  I can even rephrase your stand as a positive assertion:
> "lisp syntax is just as good as algol-like syntax".  There, now you have to
> give evidence and I don't.

Well said.  But let's dispense with the meta-arguments for the moment.  I have
never had a problem teaching Lisp.  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.

The key words here are simplicity and genericity.

Regards, [Ag]