[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
- To: masinter.pa@Xerox.COM, firstname.lastname@example.org
- Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
- From: Jon L White <email@example.com>
- Date: Fri, 9 Dec 88 17:31:12 PST
- Cc: Gray@DSG.csc.ti.com, firstname.lastname@example.org
- In-reply-to: masinter.pa@Xerox.COM's message of 9 Dec 88 09:17 PST <881209-091852-6190@Xerox>
Larry, I would very much like to see a second alternative in this
proposal. I think the idea of a "safety-net" version of REQUIRE is
fully portable, and backwards compatible with those implementations
that hook into their own "defsystem". All the arguments against it,
that have been sent out in discussion so far, are simply confusing the
issue of REQUIRE portability with that of DEFSYSTEM portability. If
someone uses implementation A's DEFSYSTEM, his code won't be portable
to implementation B (unless B has cloned A's DEFSYSTEM). There is just
no reason to indict REQUIRE of cuplability here.
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.
If you and Dan are amenable, I'd write the additional part -- from
previous mails, it should only take 10 or 20 minutes at most. Either
of you could probably write it too.
-- JonL --