barmar@think.com (Barry Margolin) (02/08/91)
In article <11922@helios.TAMU.EDU> hmueller@orca.tamu.edu (Hal Mueller) writes: >>My guess is that USES is similar to Common Lisp's REQUIRE (which the ANSI >>committee is not currently planning on including in the standard). > >What is the politically correct replacement? We're using REQUIRE >routinely; is there a better way? REQUIRE is being removed because the behavior when the module isn't already loaded is very implementation-dependent, so it's virtually impossible to use it portably. Some systems treat the module name as a file name, looked up via some implementation-dependent search path; others treat it as a defsystem-style system name, and load the system; and others use some other mechanism. If you supply a second argument, the pathname would be system-dependent (actually, we have since added logical pathnames to the language, so maybe this reason is no longer valid). Our conclusion was that since it's not possible to use REQUIRE portably, you might as well use an implementation-provided mechanism directly. When current implementations are converted to be ANSI-conformant, they'll presumably retain PROVIDE and REQUIRE in their extension packages, so converting code should just be a matter of adding package prefixes if necessary. And if you're using the second argument to REQUIRE, you can easily define it yourself as (defun require (module pathname) (unless (member module *modules*) (load pathname))) -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
mkant@glinda.oz.cs.cmu.edu (Mark Kantrowitz) (02/12/91)
In article <1991Feb8.080116.24119@Think.COM> barmar@think.com (Barry Margolin) writes: >REQUIRE is being removed because the behavior when the module isn't already >loaded is very implementation-dependent, so it's virtually impossible to >use it portably. Some systems treat the module name as a file name, looked >up via some implementation-dependent search path; others treat it as a >defsystem-style system name, and load the system; and others use some other >mechanism. If you supply a second argument, the pathname would be >system-dependent (actually, we have since added logical pathnames to the >language, so maybe this reason is no longer valid). Why didn't X3J13 decide upon some standard definition of REQUIRE's behavior? For example, have a global variable *central-registry* which contains the directory where modules are stored? My impression is that lisps use REQUIRE/PROVIDE/*MODULES* for two separate purposes: (1) Loading in implementation dependent packages, such as graphics code, CLOS, streams code, and the like. (2) Providing some sort of "MAKE" facility for common lisp. There is nothing one can do about the former, since those uses of REQUIRE are necessarily implementation dependent. However, the latter should not be implementation dependent, because that would interfere with generating portable code. By throwing modules out of the language, X3J13 has given up the chance to establish standards for such a "MAKE" facility and thereby ensure portability of system definitions. In heterogeneous computing environments, where one runs different lisps on different machines, or even on the same machine, portability of system definitions is a must. Anyway, I've written a portable common lisp implementation of systems and modules, which is available free via anonymous ftp from a.gp.cs.cmu.edu in the directory /usr/mkant/Public/. (cd to the directory in one unit, since security restrictions prevent access to intermediate directories.) The relevant files are defsystem.{lisp,ps,text}. The documentation is old and is currently being revised. --mark
barmar@think.com (Barry Margolin) (02/12/91)
In article <11891@pt.cs.cmu.edu> mkant@glinda.oz.cs.cmu.edu (Mark Kantrowitz) writes: >Why didn't X3J13 decide upon some standard definition of REQUIRE's >behavior? For example, have a global variable *central-registry* which >contains the directory where modules are stored? How would a standard global variable help? The user would still have to use implementation- and site-dependent forms to put entries into it. >My impression is that lisps use REQUIRE/PROVIDE/*MODULES* for two >separate purposes: > (1) Loading in implementation dependent packages, such as > graphics code, CLOS, streams code, and the like. > (2) Providing some sort of "MAKE" facility for common lisp. >There is nothing one can do about the former, since those uses of >REQUIRE are necessarily implementation dependent. However, the latter >should not be implementation dependent, because that would interfere >with generating portable code. By throwing modules out of the >language, X3J13 has given up the chance to establish standards for >such a "MAKE" facility and thereby ensure portability of system >definitions. We had already passed the point where we were willing to consider adding new features to the language. Perhaps if there were a fully-designed fix for REQUIRE at the time we might have been able to include it, but we didn't want to start a new project to design the fix. X3J13 has already added lots of new stuff the the language (CLOS, conditions, character repertoires, pretty-printer control). I think built-in system-building tools are going to have to wait for the next revision of the standard. ANSI CL includes better pathname primitives, including logical pathnames, with the goal being that it should be easier to write portable system-building tools. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar