[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- From: Jon L White <firstname.lastname@example.org>
- Date: Thu, 10 Nov 88 12:52:54 PST
- Cc: pierson%mist@MULTIMAX.ENCORE.COM, email@example.com, sandra%defun@CS.UTAH.EDU, Bartley@MIPS.csc.ti.com
- In-reply-to: David N Gray's message of Thu, 10 Nov 88 11:36:36 CST <2804175396-3579026@Kelvin>
- O: Gray@DSG.csc.ti.com,
I think we are very close to agreement here, providing we can stay
clear of the deeply controversial areas. Dan objects to having
non-portable features be a required part of the standard; and you
(Dave) object to having no reference to the implementation-dependent
way in which file-loading can be accomplished to "provide" a module.
How about a compromise along the lines I suggested on Nov 2? First,
say that implementations may extend REQUIRE to hook into an
implementation-specific module loading system; but Second say that
any such extension should provide a means of disabling it. That way,
one can check-out portable, pure "safety-net" applications by turning
off the defsystem hook-in [the turning off would be in an implementation
specific way, but that should be fine.]
-- JonL --
P.S.: Your example DEFINE-MODULE is slanted towards a simple loading
scheme, and certainly could be useful as it stands. However, I
would prefer to see the notion of module "provision" a bit more
abstract. In particular, the error strings to CERROR could be like:
"Require'd module ~S is not present."
"Required module ~S is neither loaded nor defined."
and the continuation string culd be more like:
"Re-try the REQUIRE call [after perhaps manually providing the module]"
"Re-try the REQUIRE call after manually loading the module."
Still, it must be admitted that we are not at all close to specifying
a standard for defsystem-like facilities.