Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!icdoc!syma!aarons
From: aarons@syma.sussex.ac.uk (Aaron Sloman)
Newsgroups: comp.lang.lisp
Subject: Re: Code as data (replies to comments).
Summary: Pop isn't better, just more readable by beginners!
Keywords: resistance to lisp
Message-ID: <1057@syma.sussex.ac.uk>
Date: 7 Jun 89 01:15:09 GMT
References: <31670@sri-unix.SRI.COM> <469@skye.ed.ac.uk> <1028@syma.sussex.ac.uk> <487@skye.ed.ac.uk> <11917@well.UUCP> <9636@polya.Stanford.EDU> <1044@syma.sussex.ac.uk> <521@skye.ed.ac.uk>
Organization: School of Cognitive & Computing Sciences, Sussex Univ. UK
Lines: 314

Well, I am sorry I raised so many hackles. The main thing to
remember is that I am not trying to knock Lisp, but rather that I
feel that AI languages like Lisp in AI development environments have
potential to be of tremendous benefit to all sorts of programmers
outside the lisp community, programmers that, so far, have not shown
much interest.

My conjecture (based on quite a number of years of watching learners
of various kinds) that syntax was, for many programmers, the main
hurdle was perhaps a way of clutching at a straw: let's agree to
offer non-lispers something with a more familiar and (at least
initially) more readable syntax (not necessarily Pop-11 -- I merely
use it for illustrative purposes, as an example, not as an ideal),
with a good set of development tools, and then maybe lots more of
those programmers will begin to appreciate the benefits we all(??)
agree AI languages and develoment environments can provide.

Well that was the hope.

But perhaps I was just being naive. Perhaps not until C has been
extended with garbage collector, built in list-processing
facilities, nested procedures with full lexical scoping, incremental
compiler(??), universal types with run-time type-checking,
integrated editor, and many other goodies, will all those people
appreciate what they have been missing?

jeff@aiai.ed.ac.uk (Jeff Dalton) writes:

> I think Lisp makes it easier (than does Pop) to see the true
> nature of macros.
Well if that is one way of putting the point that lisp makes it
easier to write macros I agreed in advance. If it means that Lisp
makes it easier to see the true nature of Lisp macros, then I guess
that's indisputable. But as for any other interpretation, I am
lost as to what "the true nature" could mean.

> In my, admittedly limited, experience, Pop-
> trained programmers tend to have a faulty understanding of macros.
I can well believe that they misunderstand how Lisp (and C) macros work
(at least initially). (And vice versa). Allan Ramsay implemented a
collection of pop-11 macro packages called "forms" that may come
closer to your notion of a macro. (See HELP FORM in Poplog).


> And the complicated syntax of other languages has turned off a
> number of people who were pleased to discover that Lisp was different.
> So there is anecdotal evidence on both sides.
The issue originally was that there is more than anecdotal evidence
that the take up of Lisp as a general purpose programming language
has been disappointing - the premiss with which someone else started
this discussion. I did not think the diagnoses offered by others
(e.g. size of lisp systems) told the whole story.

> >> ... Semantics and
> >> paradigm are much bigger issues when writing sizable programs.  As
> >> programs become larger, syntactical issues retreat in importance and
> >> issues such as namespace control and other modularity issues dominate.
>
> >Agreed - but syntax and in particular readability remain relevant when
> >someone has to maintain code written by others.
>
> I suppose someone has to say it.
>
>    Semantics and paradigm are much bigger issues when writing or
>    maintaining sizable programs.  As programs become larger, ...
>
> Do I have to continue?

I only said "remain relevant". What have I done wrong?

At first I agreed with your comment. But now it strikes me that no
matter how good the "semantics and paradigm" are, you can make the
language less useful than an intrinsically inferior one by choosing
a dreadful syntax. So it is possible for the bigger issue to be
swamped by the smaller one. (Different dimensions of bigness?) (But
I am not claiming this has happened in Lisp, though there are no
doubt some adherents of languages like ML, or even Pascal, that
would be very critical of the semantics of Lisp and Pop.)

> If neither side has performed a systematic investigation, and
> we're just going to say "I can well imagine" back and forth,
> what's the point?

The only point is that I was offering (perhaps naively?) a route for
people to TRY to get lots more programmers interested in Lisp. I am
not claiming that it is guaranteed to succeed. But I would have
thought that people who really cared might want to try, as long as
the evidence that it will fail is only anecdotal. Maybe (some) Lisp
users don't really care about all those people not using AI
languages.

(If we are to believe some of the prophets there soon won't
be any need for writing programs any way, so why bother.....)

> ...Remember that almost all of us became used to
> conventional mathematical notation, and even conventional programming
> languages, first.  Most people see 3+5, and "if ..., then ..." long
> before they see (+ 3 5) or COND, so I think your theory about what
> people are used to has little to recommend it.

I did not say that nobody could be converted to lisp after learning
a different syntax. That would have been self defeating for my
suggestion that learning lisp-like programming techniques in a
different syntax would then make it easier to get into lisp. (That's
the route our students follow.)

> Now, it's interesting that you're supposing greater cognitive
> effort is required when reading Lisp, since many people have
> found that just the opposite is true.

I was assuming everyone agreed that syntactic redundancy (within
reasonable bounds) reduces cognitive effort. Indentation is used by
lisp programmers in an attempt to increase redundancy for that very
reason. But I previously pointed to local ambiguities that
indentation alone does not resolve. (E.g. indentation as such does
not tell you, as a keyword does, that some local variables are being
declared.)

In some longish lisp programs with multi-branch conditionals (e.g.
p.323 of Abelson and Sussman), the fact that all the conditions use
a predicate name ending in "?" is an example of useful syntactic
redundancy of the kind I am saying is mostly lacking in lisp.

I suppose it is debatable whether having redundancy supplied by
conventional devices like this rather than being defined into the
language is good enough.

Anynow, if my premiss about syntactic redundancy (within bounds)
reducing cognitive load is disputed then we have to call in the
cognitive scientists who do experiments on this kind of thing.
Unfortunately the only systematic experiments I know of (by Max Sime et
al at Sheffield) only involved novices, and over a short time.

Incidentally I fear that lack of syntactic redundancy and the
cognitive load in having to memorise operator precedences, will also
reduce the take up of ML among programmers in general, though it
may be compensated for by the extra checking a compiler can do,
compared with lisp (or Pop).

>
> You also seem to be ignoring the points made about indentation.

Not ignoring them. I think indentation helps (even in richer
languages). But the point about indentation ignored my point about
needing to use extended context to disambiguate. Indentation gives
information about relative scope - but you still have to look upward
to see that "((" means "elseif" rather than something else. And as
you say, short procedures help.

> When reading well-formatted Lisp, it is almost never necessary
> to read the parentheses;
Has anyone tried using a lisp using only indentation and no
parentheses of the kind that you don't need to read? It would be an
interesting experiment, though I fear the result might be Logo.

> .....and if functions are short (as they
> most often should be), it's easy to keep one's place without
> syntactic helpers like "then" and "endif".

I agree that short lisp function definitions are easy to read.

I guess the lisp code I have found hard to read was not written
by well-trained lispers (even though some of them wrote text
books)

> >shaff@Sesame.Stanford.EDU (Mike Shaff) writes:
> >> For people who need to write code that performs analysis of one
> >> form or another, simulates, etc a program the "code as data"
> >> quality of Lisp is critical to their effort.
                        ^^^^^^^^ ( emphasis added by A.S.)
> >I suspect that what is important is that there is a well defined
> >parse-tree or similar structure that can be derived from the source
> >code and manipulated by program. Whether the external form makes the
> >parsing totally trivial (because it is all based on parentheses) or
> >not is probably far less important.
>
> The point isn't just that Lisp's syntax is simple.  It's also
> significant that there's a direct correspondence between code and
> lists.  There's no need to learn about an additional intermediate
> structure.
Yes that may be significant, in the sense that it simplifies some of
the tasks. I was simply trying to argue that it wasn't "critical",
for the reasons given. Maybe "critical" has a stronger meaning for
me than for you.

> >> I must disagree here - any macro (including most setf expanders) will
> >> depend on the similarity between data and program......
>
> >However, this does not require something like Lisp syntax.
>
> Sure it doesn't _require_ it.  But so what?
Perhaps I also misinterpreted the use of "depend on", like "critical"?

> >Pop-11 (following Pop-2) allows macros. The input stream is a
> >dynamic list of text items (words, strings, numbers etc) and a macro
> >is just the name of a procedure that reads in a portion of that stream
> >changes it and then puts back the result onto the front of the list.
>
> Sounds like a *big* pain to me.
Yes it can be, especially if you don't have tools to read in expressions,
expression sequences, etc. I said macros were easier in Lisp.

> >So "similarity between data and program" as in Lisp is not necessary
> >for macros.
>
> Of course it's not _necessary_.  So?
The comments I responded to appeared to be saying it was necessary.

> How often does the (Poplog) virtual machine have to be changed in order
> to accommodate a new language?

It needed a major change (some years ago) to speed up prolog. It
needed a minor change to cope with the fact that Lisp doesn't have a
boolean type separate from lists. It needed an extension to
implement C-like pointer manipulation in the "system" dialect of
Pop-11. It needed major changes for some of the extensions to Pop-11
(e.g. dynamic local expressions).

> ......So your point about
> the virtual machine is a point in favor of virtual machines, perhaps,
> by hardly a point in favor of (or against) Pop-11.
I am sorry to give so much offense without intending it. I was merely
responding to the apparent claim that there was ONLY the lisp way
of doing certain things (i.e. using lisp macros to provide language
extensions.)

> And, of course, languages with a syntax unlike that of Lisp can
> be implemented by translating them into Lisp.  They needn't be
> interpreted, nor follow Lisp syntax.
True. Though you can use macros only to implement things that
can be translated into lisp, just as in Pop you can use macros
only to implement things that can be translated into Pop. It is
occasionally useful to have a more general facility (though that
is stricly irrelevant to our main topic).

> >In Pop-11 a lot of program manipulation makes use of the fact that
> >you can "partially apply" a procedure to some data (including other
> >procedures) to create a new procedure.
>
> In Lisp, we tend to call them closures.
Also in Pop, but I deliberately did not use the word in case anyone
confused partially applied procedures with lexical closures, which
though useful, are, I believe less well structured (e.g. since a
lexical closure can bind any non-local variable in a procedure).

> ......And many people prefer the
> lexical approach used in modern Lisps.
Yes, it is used in Pop-11 as well, though not, I'd have thought,
for the purposes that I took this comment to be referring to:

> >shaff@Sesame.Stanford.EDU (Mike Shaff) writes:
> >> For people who need to write code that performs analysis of one
> >> form or another, simulates, etc a program the "code as data"
> >> quality of Lisp is critical to their effort.

Would lexical closures be used for performing analysis, simulating
etc?

> >The Lisp way of doing things makes you think in terms of the actual code
> >rather than in terms of the composition of procedures and data, which, I
> >suspect, is what is mostly required.
>
> Actually, Lisp doesn't _make_ you think that way at all.

I suspect from your comments on funargs and lexical closures that we
interpreted Mike Shaff differently. E.g. I think you took him to be
talking about the kind of procedural abstraction using closures that
Abelson and Sussman discuss, whereas I took him to be talking about
things that reason about programs where the similarity of code and
data in lisp would strongly incline you to think in terms of
manipulating source code. Yes - "make" was too strong!


dlw@odi.com (Dan Weinreb) writes:

> ....CGOL apparently never
> caught on with any user community.  Obviously, that fact by itself
> proves nothing about its worthiness, value, etc.  I just wanted to
> make the point that the idea has been explored in the past, at least
> two times, and therefore probably more times than that.  Just thought
> you might be interested.

Yes

aboulang@bbn.com (Albert Boulanger) writes:

> We still use this [CGOL] at BBN. In fact the infix reader for Lisp on the
> Symbolics uses a reimplementation of CGOL. (This can be extended
> somewhat.) We use the Symbolics reimplementation for reading infix
> expressions for a rule structure-editor based on presentations. I
> found that writing CGOL "productions" much more natural than dealing
> with YACC. I think a key element in CGOL for complex parsing is its
> notion of sublanguages (which the Symbolics implementation omits).

Sounds interesting. Does anyone know if any attempt was ever made to
get CGOL taken up by people outside the Lisp community, as opposed
to just trying to get Lispers to change to it?

I suspect it may now be too late for anything like this, given that
so much effort has already been put into simple-syntax lisp, and all
those text-books already exist. The last chance might have been
the year before the Common Lisp systems started coming out.

But perhaps someone with enough initiative and resources could use
the recent publication of the book on Computational Linguistics by
Gazdar and Mellish in three versions (Pop-11, Prolog and Lisp) as an
opportunity to investigate how people who know none of these
languages react to the different versions.

Aaron Sloman,
School of Cognitive and Computing Sciences,
Univ of Sussex, Brighton, BN1 9QN, England

    aarons%uk.ac.sussex.cogs@nsfnet-relay.ac.uk