Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: REQUIRE (was Re: Beginner ? - What is 'uses')
Message-ID: <1991Feb8.080116.24119@Think.COM>
Date: 8 Feb 91 08:01:16 GMT
References: <21436@hydra.gatech.EDU> <1991Feb7.173601.9840@Think.COM> <11922@helios.TAMU.EDU>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 35

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