Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!icdoc!syma!aarons
From: aarons@syma.sussex.ac.uk (Aaron Sloman)
Newsgroups: comp.lang.lisp
Subject: Re: Virtues(?) of Lisp syntax
Summary: syntax words and functions should be kept distinct
Keywords: syntax words,functions
Message-ID: <3450@syma.sussex.ac.uk>
Date: 13 Sep 90 03:34:40 GMT
References: <3368@skye.ed.ac.uk> <1350030@otter.hpl.hp.com> <3408@skye.ed.ac.uk>
Organization: School of Cognitive & Computing Sciences, Sussex Univ. UK
Lines: 169

It's interesting to see this debate surface yet again.

Jeff Dalton writes
> In my experience, in both the US and the UK, it is true that students
> often make quoting mistakes in Lisp and that they often find the
> quoting rules confusing.  I think there are a number of possible
> contributing factors.
>
> A common mistake in presentation, I think, is to make non-evaluation
> seem too much of a special case.  For example, some people see SETQ as
> confusing because it evaluates one "argument" and not another and so
> they prefer to present SET first.
    ....
>
> Indeed, the whole terminology in which SETQ, COND, etc. are presented
> as funny kinds of "functions" and where functions are described as
> "evaluating an argument" (or not) may be a mistake.

It wasn't till I read this remark of Jeff's that I realised that one
reason I don't like Lisp is that, apart from "(" and ")", Lisp
doesn't help one to distinguish syntax words and function names.

Actually, as a sort of failed mathematician, I do appreciate the
elegance and economy of lisp syntax and could probably even like
using some versions (i.e. T or Scheme, though not Common Lisp). But
for teaching most of the kinds of students I have met I would far
rather use Pop-11 which, in many ways, is similar to, and owes a
great deal to, Lisp, though its syntax is much more redundant.
(There are other differences that are irrelevant to this
discussion.)

In teaching Pop-11 I always try to get students to think in terms of
a distinction between

(a) "syntax" words (e.g. the assignment arrow "->", parentheses,
    list brackers "[", "]", "if", "endif", "for", "endfor" "while",
    "define" etc.)
and
(b) words that represent procedures (this includes functions and
    predicates, which return results, and subroutines, which don't).

Most of its syntax forms have distinctive opening and closing
brackets, e.g. "for" ... "endfor", "define" ... "enddefine" etc.
This is verbose and inelegant but it helps learners to grasp the
sort of distinction (I think) Jeff is making.

There are exceptions, like the assignment arrow "->" which looks
just like an infix procedure name, but since students don't
naturally class it with the infix operators they already know (i.e.
the arithmetic operators) they easily accept it as a different kind
of beast, playing a special and important role in their programs.
(Actually taking something from the stack and putting it somewhere,
or running  procedure "in updater mode").

Another kind of exception that helps to muddle the distinction is
the use of special brackets for constructing lists and vectors

    [a list of words]   {a vector of words}

The brackets have both a syntactic role (delimiting expressions) and
also implicitly identify functions that return results. Again these
are very special forms that are easily learnt as special cases.
(Natural languages are full of special cases: the human brain seems
good at coping with lots of special cases.)

By contrast the uniform syntax of lisp makes it not so easy to grasp
that car, cdr, sqrt, append, etc. are different beasts from setq,
cond, quote, loop,  etc. Hence the tendency to make the kind of
mistake that Jeff describes, i.e. talking about different kinds of
functions.

It should be possible to investigate this conjecture about lisp
syntax causing more confusion empirically. I wonder if anyone has?

Moreover, the syntactic redundancy involved in using different
closing brackets for each construct in Pop-11 really does make it
much easier for many readers to take in programs, which is parly
analogous to the reasons why modern lisp programmers eschew the
syntactic economy of APL programmers and use long and redundant
procedure names in this sort of style
    (sum_of_squares_of x y)
 rather than
    (ssq x y)

Having extra syntactic redundancy also makes it easier to provide
helpful compile time checks and error messages, e.g. if an editing
mistake produces
    if isinteger(x)
    else
        foo(y)
    endif

the compiler will complain:

     MISPLACED SYNTAX WORD : FOUND else READING TO then

which can be especially helpful where sub-expressions are more
complex.

> Steve wrote
> >Obviously, the attractiveness of syntax is in the eye of the beholder.
> >I have to accept that folks like Jeff are sincere when they argue that the
> >syntax of Lisp is very attractive for them.  (I am even inclined to agree
> >when the alternative is C++.)

Jeff replied
> I would agree, provided we don't take this "eye of the beholder"
> stuff too far.  It's true that different people will prefer different
> syntaxes and that we can't say they're wrong to do so.  However, we
> shouldn't go on to conclude that all views on the virtues or otherwise
> of a syntax are equally valid.  Sometimes we can say, for example,
> that someone hasn't learned good techniques for reading and writing
> code in a particular syntax and that's why they find it so hard
> to read and write.
I agree.

It should also be possible to spell out precisely the cognitive
requirements for particular kinds of learners and users at
particular stages in their development, or for particular kinds of
programming tasks, and establish the strengths and weaknesses of
alternative languages by argument and evidence and not by simply
agreeing to differ.

E.g. the use of essentially redundant keywords like "then", "elseif"
and "else" in conditionals, and the use of distinct closing brackets
like "endif", "endwhile" that remind you what sort of construct they
are terminating, has a particularly important consequence. It
reduces short term memory load, and allows local attention
focussing, by providing local cues or reminders as to the nature of
the context, whereas without them one has to parse  a larger
expression to know that something plays the role of a condition, or
a consequent. (Some lisp constructs also use these extra keywords,
e.g. "for" ... "from" ... "to". So the fault is one of degree.)

The point about memory load is an objective fact. Whether it matters
for a particular user is going to depend on the kinds of cognitive
skills that user has already developed. It's a bit like the question
whether you should repeat the key signature at the beginning of
every line in a musical score, or simply indicate it when the key
changes. For certain experienced musicians the economical method
will suffice. For most ordinary mortals the frequent reminder is
useful, even if it does increase the clutter on the page and
probably the printing costs! Note that the time signature is not
usually repeated on every line because that is (mostly) evident from
the contents of each bar, or at least determined to within a small
range of alternatives.

Another analogy is with the difference between the musical
annotation "crescendo al fine" (= get louder from here to the end),
which requires the reader to remember the instruction from there on,
and the alternative notation which has a pair of lines getting
further and further apart, immediately above or below the stave, as
a _continual_ reminder that you have to be getting louder. For many
would be performers the first form will not be as effective as
the second.

Exactly how important all these differences in syntactic redundancy
and memory load, etc. are, and in what way, will to some extent
remain unsettled until we have good theories describing the various
kinds of cognitive processes that go on in various kinds of people
when they read, or write, or design, or debug, programs.

But most designers of programming languages don't think about human
cognitive processes.

Aaron Sloman,
School of Cognitive and Computing Sciences,
Univ of Sussex, Brighton, BN1 9QH, England
    EMAIL   aarons@cogs.sussex.ac.uk