[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- To: "email@example.com"@multimax.encore.com (Sandra J Loosemore)
- Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
- From: Dan L. Pierson <pierson@mist>
- Date: Fri, 11 Nov 88 13:36:13 EST
- Cc: cl-cleanup%SAIL.STANFORD.EDU@multimax.encore.com, Bartleyfirstname.lastname@example.org
- In-reply-to: Your message of Fri, 11 Nov 88 09:35:42 -0700. <8811111635.AA00216@defun.utah.edu>
How about wording the proposal to indicate that implementations
can extend REQUIRE to load files automagically only if the user has
*explicitly* indicated (using some implementation-specific mechanism)
which files make up that module?
That would allow
(defsystem foo ....)
to work, but would prevent
from trying to load some random file named "FOO", which (as I've pointed
out earlier), may or may not contain the module "FOO".
I'm still trying to think of an acceptable compromise based on JonL's
idea. Unfortunately, this is a perfect example of what I can't accept
for the following reason:
Let's assume that the DEFSYSTEM's and REQUIRE's are part of a large,
real, potentially portable application. Say 50 files in four
directories. Somewhere in that complexity is one (or maybe four)
files containing one or more invocations of DEFSYSTEM. Almost every
one of the 50 or so files contains at least one REQUIRE. Since the
system was developed in an environment where all of this works, the
files with DEFSYSTEM are correctly loaded first thus causing all the
REQUIRE's to load files iff needed.
Let's further assume that all the rest of the code in the application
is portable because the author wanted to write a portable application
and was careful about it.
OK, now it's time to port it all. Load up a portable DEFSYSTEM (we
carefully used a simple subset of the fancy native DEFSYSTEM) and load
and compile the rest. Pity it didn't work because none of the
REQUIRE's did their normal loading functions in the new Common Lisp
implementation. Pity it's a pain to debug because all the cross
references are implicit in this maze of REQUIRE's that _used_ to work.
It really would have been much easier if the author had simply avoided
REQUIRE and represented all the dependencies in a DEFSYSTEM file that
she knew was non-portable. There's also the question: "if the
implementation had a DEFSYSTEM, why did she need to use REQUIRE to
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? An
implementation can still support whatever version of REQUIRE it wants
as an extension to Common Lisp but:
1. Users won't be fooled into believing it's a portable construct.
2. Static portablility checks will be required to warn about it.
Almost the only compromise I can think of is something that forces you
to declare the non-portable loading intent in every use of REQUIRE, say:
(REQUIRE "foo" :LOAD T)
It would be useful to hear from someone other than the 3-4 of us who
keep arguing this one.