Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

[Jon L White <jonl@lucid.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."
      rather than:
       "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]"
      rather than:
       "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.