Xref: utzoo comp.sys.xerox:345 comp.lang.lisp:1416 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!decwrl!Angelo!labrea!polya!Gang-of-Four!andy From: andy@Gang-of-Four.Stanford.EDU (Andy Freeman) Newsgroups: comp.sys.xerox,comp.lang.lisp Subject: Re: 'provide' and 'require' and compiled files Message-ID: <6508@polya.Stanford.EDU> Date: 31 Jan 89 19:44:10 GMT References: <1168@mina.liu.se> Sender: news@polya.Stanford.EDU Reply-To: andy@Gang-of-Four.Stanford.EDU (Andy Freeman) Followup-To: comp.sys.xerox Organization: Computer Science Department, Stanford University Lines: 59 In article <1168@mina.liu.se> uda@mina.liu.se (Ulf Dahlen) writes: >How is 'provide' and 'require' implemented in existing CL-implementations? >I would like 'require' to search for the compiled file first, and load it if >it's found. Xerox Lisp has a 'require' that doesn't bother about compiled >files. This makes it almost necessary to use the InterLISP function 'FILESLOAD' >and that will make programs less portable. Given this description, I can't tell where the problem is. Steele pg 188 says: "The require function tests whether a module is already present (using a case-sensitive comparison); if the module is not present, require proceeds to load the appropriate file or set of files. The pathname argument, if present, is a single pathname or a list of pathnames whose files are to be loaded in order, left to right. If the pathname argument is nil or is not provided, the system will attempt to determine in some system-dependent manner, which files to load. This will typically involve some central registry of module names and the associated file lists." Note that require's second argument is a pathname, not a string or a symbol. The string/symbol "representation" of a pathname on one implementation may not work on another implementation, but the pathname construction functions must. As to getting require to do the right thing if there are both compiled and text versions of the file, I refer readers to the description of load, on page 426. (The description of require implies that it uses load.) "If the filename (after the merging in of the defaults does not explicitly specify a type, and both text and object types of the file are available in the file system, load should try to select the more appropriate file by some implementation-dependent means." This is why it is unnecessary (in this case) for CL to specify the file type for compiled files. (It would be nice if CL defined pathname defaults constants whose implementation dependent values had the various file types, directories, etc in them, but they're not needed in this case because load does the right thing.) In other words, don't do the following: >(require 'submodule 'submodule.fasl) as (require 'submodule ) does the right thing and is portable. Did the ANSI people really eliminate require and provide (or require's second argument) because they couldn't figure this out, or was there some other reason? (If ANSI CL doesn't have pathname functions, or ANSI found a hole in CL's, then that may explain it. However, it would be better for ANSI to include pathname functions or fix the hole.) -andy UUCP: {arpa gateways, decwrl, uunet, rutgers}!polya.stanford.edu!andy ARPA: andy@polya.stanford.edu (415) 329-1718/723-3088 home/cubicle