Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!zephyr.ens.tek.com!uunet!olivea!mintaka!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.lisp Subject: Re: Greatly exaggerated reports of Lisp's demise Message-ID: <1991Feb13.051724.21056@Think.COM> Date: 13 Feb 91 05:17:24 GMT References: <1991Feb12.122415.23035@src.dec.com> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 101 In article <1991Feb12.122415.23035@src.dec.com> meehan@src.dec.com (Jim Meehan) writes: >But it would not trouble me to see call/cc added. It does trouble >me to see the new LOOP macro added. It's yet another embedded >sublanguage (FORMAT is another one, perhaps "the" other one). Look at it this way: we didn't *add* it to the language, we simply acknowledged that it is being used extensively within the CL community. This is precisely what standards committees are supposed to do. I can remember periods when someone would ask how to FTP a public domain implementation of LOOP, and the major commercial Common Lisp implementations (including Symbolics, Lucid, and Franz) all include a LOOP implementation. The problem we were addressing was that there was nothing forcing all these LOOP implementations to be consistent with each other, which just causes frustration for the programmers who wish to use it (but they still use it anyway). In the process of acknowledging it by adding the construct to the language, we also cleaned up the specification (resolving some ambiguities, removing unnecessary generality (e.g. MIT LOOP is more flexible about the placement of some clauses), and adding features necessary for consistency with the rest of the language (e.g. CL type declarations and hash table iteration)). > But maybe >the obvious thing for the committee to do is to formalize the notion >of libraries: collections of functions, macros, and global variables >that serve particular needs, so that if you don't want them, you don't >pay for them. Maybe "obvious" to you, but not to everyone. The idea of optional sections of the standard was discussed quite a bit, especially regarding the large features that were added by X3J13 (in case anyone cares, I was a member of the small contingent in favor of making certain features optional). We discussed having some parts of the spec effectively say "the fancy LOOP form isn't required, but if it is provided here is the specification." We also talked about maintaining a repository of public domain versions of some of these libraries, so that users of implementations that don't provide them could download the code. And we discussed defining explicit subset versions of the language. We eventually decided against these ideas, mostly because we simply weren't able to define the boundaries and don't have the resources to maintain the library. Note that there is nothing preventing an implementation from leaving out facilities, so long as the documentation clearly notes that such differences exist. If there's a significant market for LOOPless Common Lisps then there will probably be vendors selling them; if there isn't much of a demand for it, then X3J13 would have wasted its time defining the subset. Note that even if we had defined many functions as optional, we probably would have reserved the names in the COMMON-LISP package, so that programs originally implemented using a subset wouldn't have problems when loaded into a full language implementation, so optionalizing things probably wouldn't have helped cut down the size of the Common Lisp namespace. Perhaps if we'd relegated them to their own packages, but I think there was resistance to usurping too much of the package namespace. > As an AI programmer, I'd have relegated all those math >functions (branch cuts, etc.) to some distant shore, too. Here's an example of why it's hard to define subsets: "All those math functions" includes ordinary arithmetic. I suspect even AI programs need to add integers once in a while. > The object >system is crucial; the pretty-printer is not. Hmm, I think the pretty-printer interface was needed mostly to allow object-oriented programmers to control the pretty printing of their objects, since the built-in types already interact with it. >Of course, having the wealth of choices for writing the same code is >not always a good thing. We had an in-house "Common Lisp style sheet" >that included, among other advice, a list of "forbidden forms," whose >use you would have to justify to the company's Programming Czar, who >almost never let you get away with anything. The Forbidden List >included DO*, RPLACA, RPLACD, PROGV, any C{A,D}R function with more >than two letters between the C and the R (and those only for plists), >and others. There was also a Restricted-Use List, including APPEND, >PROGN, BLOCK, etc., where there were specific cases where they could >be used, but not elsewhere. The programmers liked this. It promoted >useful discussion, especially among Lisp newcomers, it enhanced >readability, and it spared them age-old hassles. When I worked at Honeywell programming Multics we had a similar guide for PL/I, and I thought this was a great policy. It was mostly a guideline, but it assisted during the required code audit by another programmer (there were some stronger requirements for kernel and security-related code). >On the issue of REQUIRE, we viewed this as a simple mechanism >appropriate for simple programs. With large-scale programming, you >need a whole suite of program-management tools, so I don't think that >the committee was being "a little unfriendly" as Vance Maverick notes, >but simply realistic. Thank you for a user's viewpoint. Another way to describe X3J13's view about REQUIRE is that it lulled many users into thinking that it was more than it really was. Given the generality of the rest of the language, I can understand why someone might expect REQUIRE to be more than an extremely limited facility. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar