Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!mcsun!ukc!edcastle!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: What replaces REQUIRE Message-ID: <4133@skye.ed.ac.uk> Date: 14 Feb 91 16:09:15 GMT References: <21436@hydra.gatech.EDU> <1991Feb7.173601.9840@Think.COM> <11922@helios.TAMU.EDU> <10901@pasteur.Berkeley.EDU> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 70 In article pierson@encore.com (Dan L. Pierson) writes: >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." [And then: some systems actually do determine which files to load in an interesting way. Some programmers might think that, because REQUIRE is part of standard CL, this interesting behavior is standard too. But it isn't. A proposal to make REQUIRE portable and thus rule out the interesting behavior provided by some systems was resisted. So it was decided to not make anything about REQUIRE standard and let implementations do whatever they wanted (as an extension to std CL).] I think this is the best explanation posted so far (thanks Dan!), and this is not the first time the issue has come up. On the whole, I think it probably _is_ better to take REQUIRE out of standard CL. It was confusing to call what PROVIDE and REQUIRE did "modules" (given what module means in languages that "have modules", such as Modula-II), and it was far from clear that PROVIDE and REQUIRE would fit into any good, portable system defining and building tools that were eventually developed. It used to be possible to write large-ish Franz Lisp programs using something sort of like REQUIRE (called "environment") together with a Makefile (Franz is Unix after all). In Common Lisp I eventually gave up and wrote a simple DEFSYSTEM. Still, I think REQUIRE could be used in that way, and the basic functionality of being able to tell if something has already been loaded is so generally useful that I think it's a shame not to have some standard way to do it. Moreover, it _is_ possible to use REQUIRE portable, or at least that's my interpretation of CLtL (and that of some other people who have posted in the past). In CLtL II, page 278, we find: The _pathname_ argument, if present, is a pathname or a list of pathnames whose files are to be loaded in order, left to right. If the _pathname_ argument is NIL or not provided, the system will attempt to determine, in some system-dependent manner, which files to load. I take it that this implies that if the _pathname_ argument is provided and is not NIL, then the system will load the specified file(s) and NOT attempt to determine, in some system-dependent manner, which files to load. I realize that it's possible to argue that when something says "If X then Y. If not X then Z" that this doesn't strictly imply that if X, then Z won't be done; but I think such a reading would be a little perverse. We could go on to say that _pathnames_ aren't portable, but I don't think that's very convincing. So, I think it's understandable that some people would think X3J13's decision to de-standardize REQUIRE was a bit arbitrary and against the interests of users. I think it's understandable but, as I said, on balance I think the decision was correct. All that's lacking is a complete explanation, which I think we now almost have. -- Jeff