Path: utzoo!utgpu!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: Re: REQUIRE (was Re: Beginner ? - What is 'uses')
Message-ID: <1991Feb11.225118.21951@Think.COM>
Date: 11 Feb 91 22:51:18 GMT
References: <11922@helios.TAMU.EDU> <1991Feb8.080116.24119@Think.COM> <11891@pt.cs.cmu.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 38

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