Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!think.com!paperboy!hsdndev!husc6!encore!pierson From: pierson@encore.com (Dan L. Pierson) Newsgroups: comp.lang.lisp Subject: Re: What replaces REQUIRE Message-ID: Date: 13 Feb 91 15:43:36 GMT References: <21436@hydra.gatech.EDU> <1991Feb7.173601.9840@Think.COM> <11922@helios.TAMU.EDU> <10901@pasteur.Berkeley.EDU> Sender: news@Encore.COM Organization: Encore Computer Corporation Lines: 56 Nntp-Posting-Host: xenna.encore.com In-reply-to: maverick@fir.Berkeley.EDU's message of 8 Feb 91 00:28:07 GMT In article <10901@pasteur.Berkeley.EDU> maverick@fir.Berkeley.EDU (Vance Maverick) writes: It seems that ANSI is just dropping the module feature. Apparently we are all to roll our own. I quote: "XJ13 commented that the file-loading feature of REQUIRE is not portable, and that the remaining functionality is easily implemented by user code." (CLtLII p.277) This is true but a little unfriendly, and invites portability problems. The problem is that including REQUIRE *in the standard* enforces portability problems. The argument goes like this: 1. The file loading feature of REQUIRE is speced to be non-portable, "If the pathname argument is nil or is not provided, the sytem will attempt to determine, in some system-dependent manner, which files to load." 2. Some current implementations such as TI Explorer and Coral Common Lisp (now Allegro Common Lisp for the Mac or some such), include and depend heavily on powerful, useful, very system-dependent implementations of the above. For example: in Coral (require 'quickdraw) is the standard way to access the Mac-specific graphics extensions. 3. A proposal to delete the second argument of REQUIRE and restrict it to just the portable functionality was very strongly resisted by the implementors who would be hurt by it. 4. (here is where it gets tricky) Standardizing REQUIRE including the non-portable parts is a portability trap. Let's say you're developing what you fondly think will be a large portable application on an Explorer. Since REQUIRE is portable, you use it in lots of places to ensure that your inter-module dependencies are satisfied. It works just fine; everything you need is always correctly loaded. Now you move your finished application to a major stock-hardware Common Lisp (or worse, give it to someone else to move). Everything breaks with a complex, undoumented network of unsatisfied dependencies because REQUIRE on the Explorer not only check to see if dependencies were satisfied, it fixed them up with system-dependent magic. This is not a bad feature, but it *is* a non-portable one. What fooled you was the official lie that REQUIRE was a portable function that you could safely use in portable code. 5. (the important part) Removing REQUIRE from the standard does not mean that implementors must, or even should, remove it from their implementations. It merely means that it should be described as what it is: an implementation dependent extension. (The standard does require that such symbols live in a package other than COMMON-LISP. However, USER can use system-dependent packages so authors of non-portable code shouldn't have to notice any change.) -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com