Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!ukc!etive!aiai!jeff
From: jeff@aiai.uucp (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Code as data (replies to comments).
Keywords: resistance to lisp
Message-ID: <525@skye.ed.ac.uk>
Date: 8 Jun 89 18:24:52 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> <1057@syma.sussex.ac.uk>
Sender: news@aiai.ed.ac.uk
Reply-To: jeff@aiai.uucp (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 206

In article <1057@syma.sussex.ac.uk> aarons@syma.sussex.ac.uk (Aaron Sloman) writes:
>Well, I am sorry I raised so many hackles.

Why do you think you've raised hackles?  You posted an article, some
people replied.  Seems perfectly normal to me, except that there are
so few flames.  (You should try some of the other newsgroups.)

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

It's certainly true that many programmers haven't shown much
interest.  But it's less clear that Lisp's syntax is the main
reason.

Maybe you're right, but how would we know?  To those who dislike
Lisp syntax, it will sound plausible that the syntax is what puts
people off, but not everyone dislikes Lisp syntax (just as not
everyone dislikes vanilla ice cream).

I find Pop harder to read than Lisp.  In part, that's because I'm used
to Lisp.  But my preference for simple syntax is not because I'm used
to Lisp -- it's one of the reasons I became interested in Lisp in the
first place.  And I'm not used only to Lisp, I'm used to several other
languages as well.

I don't think that, in the end, readibility is something about
which everyone will agree.  Still, none of this says there aren't
some people who'd prefer Pop's syntax.  So you're probably right
that some people might take up an "AI language" if it had a syntax
other than Lisp's.

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

Note that I didn't say "nature of Lisp macros".  I didn't want to go
into details in a message that was already too long, but what I had in
mind as the "nature" was that macros were source-transformations.

I can't show that Lisp really does make it easier to see this, though.

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

The issue here is Lisp syntax.  If we try to discuss too much in each
message they'll be too long for anyone to read.

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

It looked like you thought the situation was significantly different
when you took maintenence into account.  But you gave no reason.
And, indeed, that was all you said in response to the claim that
syntactic issues retreated in importance for large programs.
I thought the claim deserved a better response.

>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.  [remarks about semantic conparisons omitted]

But the issue is _Lisp_ syntax, not some hypothetical "dreadful" one.

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

You said:

  I can well imagine that someone brought up on and/or very used to
  Lisp will find the extra syntactic clutter [in other languages]
  objectionable whereas for others it might make the language far
  more approachable

The issue was not whether someone could be converted to Lisp, but
whether people people who preferred Lisp-style simplicity did so just
because they were used to it.  That may be true in some cases, but it
leaves unanswered the question of why anyone wants to use Lisp in the
first place, especially if what one's used to is so important.  (No
one starts off being used to Lisp.)

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

Anyway, my point is that the triviality of parsing isn't what is
claimed to be better about Lisp.  It's, in part, that the parsing
doesn't happen at all (ie, the correspondence is direct).

"Critical" aside, you seem to think an intermediate parse tree 
structure is good enough.  But it it?  Maybe it makes an important
difference if the correspondance is more direct.

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

I don't see where offense comes in.  I wasn't offended.  But things
often sound more extreme in these electronic messages than they were
intended to be.

But I don't think you had more in mind than showing Lisp wasn't the only
way to do things.  If all you wanted to show was that Lisp wasn't the
only way to get language extensions, you could have done it in one
line, like "C has macros.".  You also wanted (at least) to tell us
something about Pop.

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

I think you are wrong about lexical closures being less structured.

Perhaps it matters how you think about them.  Lexical closures don't
bind non-local variables.  There's already a binding, and, in the
procedure, a reference to it.  All the lexical closure does is to
give that reference indefinite extent.  That is, it doesn't become
invalid just because the expression that introduced it that non-
local variable exits.

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

Would Pop closures?  You brought in closures, and I just
responded to what you said.

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

Actually, I did not interpret Mike Shaff in the way you suspect.
You introduced closures, and that's why I commented on them.

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

I've looked at the three versions and would not regard this as a valid
comparison.  It would still be interesting, but I don't think the
different versions are sufficiently equivalent for language choice
to be the only factor that's significant.  There are lots of different
ways to write the Lisp code, for example.

-- Jeff