[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)



re: 
	My "compromise" proposal, that Gray seemed to agree to, was to insist
	that implementations which "hook" their REQUIRE into some  kind of 
	DEFSYSTEM -- as an implementation- specific extension -- must also 
	provide a special variable flag that disengages any such "hook-up".  
	While it is true that many people will persist in writing non-portable 
	code, the portable use of REQUIRE to ensure that required package 
	definitions are "already loaded in" is of paramount importance.  There
        is no other portable feature to help ensure that.

    I don't buy this.  You can do it portably with find-package and intern.
    You might claim that is gross, but I don't believe it.  . . . 

The point underlying this claim has been re-iterated several times during
the discussion of this issue, but let me try again.

  -- a REQUIRE used in an implementation that can hook into a defsystem
     will trigger that loading.  There is no portable way to do so now
     [doesn't matter that the hook merely errors out for implementations
     that don't have a defsystem, or for which the user failed to supply
     the appropriate database].  REQUIREs which supply explicit filenames
     are not portable -- that's precisely how this proposal got started.

  -- any REQUIRE is expression of intent on the part of the programmer.
     REQUIREs are in common usage around the community, and they are 
     especially useful in package "requirements".  All such expressions
     are portable.  

But I have no idea what you mean by suggesting that these usages of
REQUIRE can be replaced by some idiosyncratic usage of FIND-PACKAGE etc.

Incidentally, the point about "expression of intent" was said much
better by Larry last October:

    Date: 18 Oct 88 14:13 PDT
    From: masinter.pa@Xerox.COM
    Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 

    The thing that distinguishes PROVIDE and REQUIRE from their obvious
    implementations is that they have declarative rather than operative
    semantics. Program walkers, DEFSYSTEM constructors as well as compilers
    might be expected to pay special heed to PROVIDE and REQUIRE, but not pay
    any special heed to direct manipulation of *MODULES*.

    We should be careful in the standard to distinguish between what things
    mean and how they may be implemented, but doubly so in the case of macros
    and special forms that may get processed at times other than EVAL-time.


-- JonL --