Xref: utzoo comp.lang.lisp:3609 comp.lang.scheme:1638 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!sdd.hp.com!ucsd!ucbvax!agate!stew.ssl.berkeley.edu!ericco From: ericco@stew.ssl.berkeley.edu (Eric C. Olson) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: Virtues of Lisp syntax Summary: syntax vs representation Keywords: lisp opinion Message-ID: <1990Sep7.195837.24793@agate.berkeley.edu> Date: 7 Sep 90 19:58:37 GMT References: <1990Aug26.205018.18067@cbnewsc.att.com> <1350028@otter.hpl.hp.com> <3368@skye.ed.ac.uk> <667@argosy.UUCP> Sender: usenet@agate.berkeley.edu (USENET Administrator) Organization: University of California, Berkeley Lines: 31 People often confuse the printed representation of Lisp with its actual representation. That is, Lisp functions are lists with the symbol lambda as its car. It happens that the common Lisp readers use a fairly direct representation of Lisp functions, namely the body of a defun function. However, one could imagine a defun-algol function that translates algol like syntax to Lisp functions. Additionally, one could have a print-algol function that would coerce Lisp functions into algol like print representations. I think of Lisp as a algorithmic assembler. It allows the programmer to deal with the issues of a problem without getting involved in the details of a specific machine. Often times, its useful to implement a new language on top of Lisp to provide data abstraction. A rule based expert system comes to mind. Its easy to translate into Lisp from a language using another syntax. The reverse is in not true. Especially with advent of aggresive automatic translators. Which for example, prove whether or not a binding can be allocated on a stack instead of a heap (in a Lisp to C translator). The only other type of language that provides this level of functionality are stack oriented languages. I find them more difficult to understand -- perhaps because they don't have all the development tools that other languages have. IMHO, Eric Eric ericco@ssl.berkeley.edu