[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- To: gz%spt.entity.com@multimax (Gail Zacharias)
- Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Tue, 18 Oct 88 15:27:25 EDT
- Cc: cl-cleanup%sail.stanford.edu@multimax
- In-reply-to: Your message of Tue, 18 Oct 88 13:51:04 -0400. <8810181351.AA19036@spt.entity.com>
If (PROVIDE x) can't be anything but (push x *modules*) and
(REQUIRE x) can't be anything but (or (member x *modules*) (error
'require-error x)), what's the point of putting these two
functions in the language? Users can just be told that one neato
way of specifying interdependencies is by pushing things on a
variable called *modules*. I don't see any point in having
PROVIDE/REQUIRE if nothing magical is allowed to happen and if
users have to write their own system-loading functions even in the
simplest cases. They just take up two nice names that users might
be able to put to a better use.
The first proposal _was_ to just remove these from the language. JonL
convinced several of us that this shouldn't be done because the
functions are useful as a safety net behind a real defsystem
facility. If we can't agree on the stripped versions of PROVIDE and
REQUIRE, the total removal proposal will probably resurface because
the current definitions simply aren't portable and can't be made
portable without a lot more environment definition that anyone seems
willing to mandate.
Personally, I totally oppose any proposal that makes PROVIDE and
REQUIRE only work if all of your files are in the same directory; most
systems have tree-structured directories, they're there for a reason,
and large systems (the type that most need this feature) need to have
their sources distributed across multiple directories.
By the way, the proposed definition of REQUIRE is closer to:
(or (member x *modules*) (cerror 'require-error x))