Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!edcastle!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: Greatly exaggerated reports of Lisp's demise Message-ID: <4126@skye.ed.ac.uk> Date: 13 Feb 91 16:57:14 GMT References: <1991Feb12.122415.23035@src.dec.com> <1991Feb13.051724.21056@Think.COM> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 95 In article <1991Feb13.051724.21056@Think.COM> barmar@think.com (Barry Margolin) writes: >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. I thought there was a file at MIT that everyone was supposed to be able to use. It was the standard implementation, at least in intent. I agree that it helps to agree on a standard specification. However, I also think it makes sense to divide the language at least conceptually into parts. Core language + libraries is a well-stablished way to make such divisions. Moreover, I think that can be done with the language as currently defined. Part of the reason some people think CL is a giant, monolithic language is due to how it's been presented and to how implementations have worked -- ie, for essentially historical reasons. Indeed, the current "definitions" of CL (CLtL, the X3J13 draft) can be understood in a more structured, less monolithic way. I've tired to make this point in several articles, because in my experience this sort of criticism is very frequent and I think it is, in part, a misunderstanding. However, Common Lisp could be better in this respect. >Maybe "obvious" to you, but not to everyone. That's a pretty much universal problem with "obvious", I think. > 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 making some things "library" doesn't mean thay must be optional. We could require that all implementations provide those procedures. (Sort of like "hosted" implementations of C and the standard i/o library.) Of course, there could also be other libraries that aren't part of the standard. I think subsets were rejected for several reasons, and among them: * It would difficult to find the right subsets, given that there are several ways to do it and that people have different interests. (This is where libraries have an advantage. To a large extent, you can mix and match.) * It was felt that there wasn't much point to subset implementations because they could become full implementations by loading some pd code from CMU. (Actually, they'd probably have to change the code a bit, or change their implementation, not just load it). * Subsets were associated with the idea of optional parts of the language. That looked like it might be bad for users. (The possible advantages to users weren't much noticed.) And it might threaten the status of some of the later additions to the language. CLOS fans didn't want it to be optional, for example. * Most people in X3J13 weren't very interested in subsets. It was the sort of thing _critics_ of Common Lisp kept going on about, and they probably wouldn't like Common Lisp no matter what concessions were made. >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. I don't think that would be too much of a problem in practice. Just as we have names in the LISP package such as STANDARD-OBJECT, we could have package names such as STANDARD-. Or we could, as you suggest, have the standard library routines be in the LISP package. -- jd