Xref: utzoo comp.lang.lisp:3624 comp.lang.scheme:1653 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!milano!cadillac!pebbles!ned From: ned@pebbles.cad.mcc.com (Ned Nowotny) Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: Virtues of Lisp syntax Message-ID: <11048@cadillac.CAD.MCC.COM> Date: 11 Sep 90 16:13:13 GMT References: <1990Aug26.205018.18067@cbnewsc.att.com> <1350028@otter.hpl.hp.com> <3368@skye.ed.ac.uk> <667@argosy.UUCP> <33695@cup.portal.com> <33709@cup.portal.com> <1990Sep10.091911.20877@hellgate.utah.edu> Sender: news@cadillac.CAD.MCC.COM Reply-To: ned%cad@MCC.COM (Ned Nowotny) Organization: MCC CAD Program, Austin, TX Lines: 48 In article <1990Sep10.091911.20877@hellgate.utah.edu> kessler%cons.utah.edu@cs.utah.edu (Robert R. Kessler) writes: =>RLISP was an Algol-like Syntax that was a translator into Portable =>Standard Lisp. To those of us who implemented and subsequently used =>it, there were many mixed views. Some people felt that they liked it =>because they didn't like the ``ugly'' Lisp syntax. They still had =>access to all of the Lisp operations, but didn't have to put up with =>the parens (remember that when we were RLISP, we didn't have fancy =>text editors that did paren bouncing, auto-indentation, etc -- try =>writing Lisp code without the editor features, it really is much more =>difficult). The others among us, felt that RLISP just got in the way, =>so we used PSL. RLISP has currently diverged some what. PSL is still =>be distributed (by us and others) and supports a flavor of RLISP. =>That version is still in use by the Alpha_1 group here at Utah which =>has a solid modelling package, which has a mode where the users can =>define models in RLISP. The REDUCE algebra system (which is also =>still being distributed) has a slightly different version for =>supporting computer algebra (in that case, RLISP works well -- the =>most common users of REDUCE are non-computer scientists who find =>things like infix operators a requirement). In so far as extension languages are concerned, this is the most important argument against unsugared Lisp syntax. Most people learned mathematics with infix operators and most people are more accustomed to communicating in a written form where keywords and separators are the typical delimiters, obviating the need for parenthesis or bracket matching. In fact, most users are not persuaded by arguments that Lisp syntax is "elegant" or "easy to learn." They are far more likely to believe that the programmer was to lazy to build a simple parser and therefore decided, because of the obvious intrinsic value of the product, that the user should be willing to be the parser for an otherwise unfamiliar notation. This attitude, at best, is not customer-oriented and, in any case, is unproductive. Parsing technology is well developed. Extension languages can fairly easily accommodate an ALGOL-like syntax while still providing all the semantics of Lisp (or Scheme, for that matter.) =>Finally, there is =>something called RLISP-88 from Rand, which has extended RLISP with =>concurrency operations, an object system, and other neat features. => =>B. Ned Nowotny, MCC CAD Program, Box 200195, Austin, TX 78720 Ph: (512) 338-3715 ARPA: ned@mcc.com UUCP: ...!cs.utexas.edu!milano!cadillac!ned ------------------------------------------------------------------------------- "We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.