[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- To: sandra%defun@cs.utah.edu
- Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- From: gz@spt.entity.com (Gail Zacharias)
- Date: 18 Oct 88 13:51:04 EDT (Tue)
- Cc: pierson%mist@MULTIMAX.ENCORE.COM, cl-cleanup@sail.stanford.edu
- In-reply-to: Sandra J Loosemore's message of Tue, 18 Oct 88 09:40:02 MDT <8810181540.AA22872@defun.utah.edu>
Coral currently "decides that a module has been provided" if the module has
been loaded as the result of a previous REQUIRE or is in the process of being
loaded as the result of a REQUIRE. This mode of operation has the advantage
of making it possible to handle both aborted loads and recursive dependencies
correctly. I realize that the concept of "loaded as the result of a REQUIRE"
is less clear with the current proposal, but I'm not convinced that it becomes
entirely meaningless and would not want to disallow these sorts of extensions
out of hand.
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.