Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!odi!dlw From: dlw@odi.com (Dan Weinreb) Newsgroups: comp.lang.lisp Subject: Re: Code as data (replies to comments). Message-ID: <382@odi.ODI.COM> Date: 10 Jun 89 23:02:27 GMT References: <1057@syma.sussex.ac.uk> <1350020@otter.hpl.hp.com> Reply-To: dlw@odi.com Organization: Object Design Inc., Burlington, MA Lines: 78 In-reply-to: sfk@otter.hpl.hp.com's message of 9 Jun 89 19:44:02 GMT In article <1350020@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Stephen Knight) writes: As far as I am concerned, any language which makes me write (+ x (* y z)) has made a rather dubious compromise. It's a very important benefit of Lisp that there is no distinction between "built-in operators" and "user-defined functions". They are treated equally, and therefore have the same syntax. This is important because (1) Lisp is an extensible language; there must be no system/user distinctions, and (2) because functions are manipulated at runtime so frequently. For example, "mapcar" works the same way with all functions, built-in or your own. Meanwhile, Lisp also has the advantage that nobody has to learn a bunch of arbitrary "precedence rules"; everything just works in the obvious way. For people who *really* want infix arithmetic (usually people writing heavily math-oriented code in Lisp -- it does happen), some dialects of Lisp (e.g. Symbolics) provide an infix syntax as well. Outside the Lisp community, the syntax is widely considered to be a laughing matter. It's gratifying to see that this conversation is being kept on a rational, intellectual plane. One doesn't have to go very far before noticing some very strange things about Lisp syntax. In just about all the cases you listed, there's nothing "very strange"; these things are simply different from what you are familiar with. Many choices in language design are essentially arbitrary. In some other cases, your point has been answered by previous postings. In some cases, there are awkward things in mainstream Lisps that are indeed hangovers from the past and cannot be changed in mainstream Lisp for compatibility reasons, but none is important. Some are fixed in Scheme, which doesn't have those constraints. Why denote vectors with #( ... )? Why not use different brackets? Why use brackets? Why not use #( ... )? The actual reason is that brackets were intentionally reserved for user extensions; all system extensions were put on # in order to help keep out of the way of the user. One of the unusual design criteria of Lisp is that people often use it to create their own embedded languages, and this little decision makes it a bit more convenient for some of them. On the topic of macros, there is actually a need to write in a disciplined fashion. One might be tempted to think that (f E1 ... En) means apply f to the results of E1 to En. However, if "f" is a macro, there is no obligation for it to evaluate E1 to En, at all. It might quote bits of them, evaluate bits of them, or anything at all. Furthermore, any errors reported will be described in terms of the resultant code -- which you may well be completely unaware of. Yes, that's inherent in the concept of an extensible language; the reader of a program has to know the extensions. Often macros have names chosen according to certain conventions, to make them easy to recognize in some common paradigms. You also have to know the Lisp special forms like "quote" and "defun". The only way to "solve" this "problem" would be to take away one of Lisp's most important features: true uniform extensibility. If you don't want a uniformly extensible language, use some other language. Why are atoms quoted with a single quote at the start? Everything is quoted with a single quote at the start, not only "atoms". There's no need for a close quote; it would be entirely redundant. I have never, in my whole life, heard of anyone having trouble due to this. You can pick at little issues all day, but if nobody is actually being harmed, they don't carry much weight. Lisp's syntax is a compromise between uniformity and readability. Of course, I disagree strongly. It's the most readable thing there is, in my opinion. As I said earlier, I certainly agree that it puts people off, but only because it's unfamiliar, not because there's anything wrong with it.