Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

[Jon L White <jonl@lucid.com>]

re: Once again, if you allow REQUIRE to load files it isn't portable and
    code written in implementations that support it will be harder to
    port (I haven't thought enough about the possible problems of going
    from a non-loading implementation to a loading implementation).
    If the feature isn't portable, why keep it in the language?  ...

Sorry to have to "chime in" again, but this goes to the crux of the
matter.  [Anyway, I think it's likely that only the four of us are
deeply concerned about the issue, and that if we can come to some
agreement amongst ourselves, then that will carry much weight with
the committee as a whole.  If the four us can't agree by deadline
time, then it's surely hopeless.]

David (Gray) suggested not that the standard allow REQUIRE to "load
files", but that an allowable extension be the interface to an
implementation-specific "defsystem", if one is available.  Thus he 
wants to reserve space for an interface, which in some implementations 
will just be an interface to the null feature!  A programmer who comes 
to depend on a given vendor's defsystem has a porting problem completely
independent of whether or not that vendor also made a non-portable
extension to REQUIRE.  [by the way, I use "DEFSYSTEM" to refer to this
interface, despite the fact that an entry from REQUIRE probably calls
"MAKE-SYSTEM; it's just that MAKE-SYSTEM is usuless without DEFSYSTEM.]

The advantage of this is that ***if*** one ports his code to a system
with a compatible defsystem, or ***if*** he ports his system specification
first, then the module-name interface in the one-argument version of
REQUIRE doesn't need any further porting.

On the other hand a truly _portable_ program must disable any defsystem
hooks.  I don't particularly mind if such disablement isn't standardized;
it all "comes with the territory" when you buy the big hamburger from a 
Lisp vendor.  Namely, the portable program writer has to figure out how to
configure his "hamburger" to have only the standardized, portable features,
in order to certify his work as portable.  And as we all agree, the only 
portable part of REQUIRE is the "safety net" part -- not the incestuous 
hook-in.  Remember FIXNUM-NON-PORTABLE!

Thus I'd rather add a new special-variable parameter with values T or
NIL than to force the step of backwards incompatibility on the current
REQUIRE users.  Many of these users are quite happy to see their
(REQUIRE "foo") simply load the file "foo" from the connected directory.
Forcing these people to go back and change all their code WHICH THEY
WOULD NEVER BE PORTING ANYWAY is not a guaranteed way to win friends and
influence people favorably towards this proposal.

Still, I don't see the situation as all that bad, because there really 
aren't that many programs around that are intended to be fully portable. 
[Of course, the coder of such ported programs may suffer complaints from
end-users who notice that he didn't hook into their own defsystem; but
we can at least take REQUIRE off this particular hot-seat.]  In fact, 
most Lisp users run on precisely one vendor's system, and could care 
less about full portability.  As some have suggested, what CL gives us 
is "portability of programmers" more than portability of particular
programs.

The "compromise", as I see it, is aimed a retaining a useful portable
meaning for REQUIRE, but not breaking existing code.  That is why we
have to say something about allowable, implementation-specific 
extensions, and how to disable them.



-- JonL --