Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!uunet!mcvax!ukc!etive!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: Code as data (Syntax, macros, run-time compilation) Summary: Pop isn't better Keywords: resistance to lisp Message-ID: <521@skye.ed.ac.uk> Date: 4 Jun 89 19:20:18 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> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 183 In article <1044@syma.sussex.ac.uk> aarons@syma.sussex.ac.uk (Aaron Sloman) writes: >My original posting on the unfortunate effects of Lisp syntax produced a >number of comments and stirred up a discussion of code as data. This >message attempts to separate what is important about this in lisp from >what is superficial. I think you will find that people disagree about what is important. You may well say that all of the important aspects are shared by Pop-11, but that might not be the case. Perhaps it's important that Lisp's syntax is simple and corresponds directly to lists. I think Lisp makes it easier (than does Pop) to see the true nature of macros. In my, admittedly limited, experience, Pop- trained programmers tend to have a faulty understanding of macros. >In particular I try to show that the syntax of >lisp has nothing to do with the possibility of having macros Of course macros are possible with a different syntax. C has macros. Assembler has macros. So it's trivial to show this, and not very enlightening. >and that not all cases where code has to be treated as data require >the original source code to be manipulated. So? It's seldom the case that all cases require anything. >My main point in raising this issue was that the syntax of Lisp has had >the effect of turning off a number of experienced programmers who might >otherwise have been tempted to get into AI tools and techniques. 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. >> ... 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? >> Most of the attempts to make LISP look like Pascal or one of its >> descendants result in a syntax that is more, rather than less, painful. >Painful for whom? Has this been investigated systematically? I can >well imagine that someone brought up on and/or very used to Lisp will >find the extra syntactic clutter objectionable whereas for others it >might make the language far more approachable (as Pop-11 has proved >to be for many experienced programmers.) 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? But if you want to play this game, it's worth asking why some people prefer Lisp's syntax. 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. And this brings us to: >> .... When I was learning lisp, at first it was its syntactic >> consistency which was probably the most attractive attribute. >Yes - there are many people who react like that, especially people >with mathematical aptitude and training. However, there are also >many (including some experienced programmers) who are put off by the >cognitive effort that is required because of the syntactic economy. 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. You also seem to be ignoring the points made about indentation. When reading well-formatted Lisp, it is almost never necessary to read the parentheses; 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". Indeed, I find code harder to read when it's full of "endif" and the like. >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. >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. >mthome@bbn.com (Mike Thome) writes: > >> In article <11917@well.UUCP> nagle@well.UUCP (John Nagle) writes: >> >On the other hand, the fact that data and programs have the same >> >representation in LISP really doesn't seem to be used all that much >> >any more. It was felt to be terribly important at one time, but today, >> >it just doesn't seem to be a big issue. >> >> 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? >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. >So "similarity between data and program" as in Lisp is not necessary >for macros. Of course it's not _necessary_. So? >>.......Personally, I've been >> working on a number of different projects which build (sometimes compile) >> routines at runtime. > >This is a standard facility in Pop-11. In fact, Pop-11 procedures >are provided for planting instructions to the Poplog virtual >machine, which can then be compiled. This enables Poplog Pop-11 >to be extended with languages like Common Lisp, Prolog, Scheme and ML >without requiring them to have anything remotely like the syntax of >Pop-11, and without requiring them to be interpreted: they all compile >to machine code. How often does the virtual machine have to be changed in order to accommodate a new language? Besides, the virtual machine isn't part of Pop-11 -- it's part of the PopLog system, which, after all, is just one possible implementation of Pop-11. 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. 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. >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. Some things, like Pop's "open stack", make Pop's partial applications somewhat different from what's offered by modern Lisps. But the ability to use function rather than just their source code (so to speak) is there in both languages. And many people prefer the lexical approach used in modern Lisps. Pop does have some advantages, and does have some uniformity that Common Lisp lacks. (For example, Pop's equivalent of hash tables can be used as if they were functions.) ML has some advantages as well. It should also be said that Pop treated functions a first-class objects before this notion achieved it's current popularity in the Lisp community. The criticism you make in the next paragraph used to make more sense than it does today. (Though, to be fair, even Lisp 1.5 funargs could be used as functions of more or less the right sort.) >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.