Re: Adding load-only source files to ASDF

Robert Goldman <[email protected]> Thu, 15 Feb 2007 21:07:44 -0600
Newsgroups gmane.lisp.cclan.general
Message-ID <[email protected]>
Richard M Kreuter wrote:
> Richard M Kreuter <[email protected]> writes:
>> Richard M Kreuter <[email protected]> writes:
>>
>>> In fact, if you're willing to use just a class, I think you can
>>> implement the functionality as an extension using asdf's protocols...
>> ...maybe the right way to implement a load-only component would be
>> to have load-op depend on load-source-op for such components...
> 
> The code in my last post in this thread was broken.  I deleted some
> defmethod forms, but forgot to remove the methods from the Lisp I was
> working in.  Sorry about that.
> 
> However, in working on fixing it, I noticed a problem: COMPILE-OPs and
> LOAD-OPs still get PERFORMed on the load-only file.  Even if the
> default primary methods of COMPILE-OP and LOAD-OP do nothing, that
> they are PERFORMed at all is arguably a flaw: subclasses of COMPILE-OP
> or LOAD-OP can have methods that probably shouldn't be run at all on
> load-only files.  For example, subclasses' methods might assume that
> fasls exist after COMPILE-OP or before LOAD-OP on generalized
> instances of CL-SOURCE-FILE, but this will be false for load-only
> instances implemented as has been discussed.
> 
> For COMPILE-OP, the solution is easy: have OPERATION-DONE-P return
> true for COMPILE-OP and LOAD-ONLY-CL-SOURCE-FILE, and TRAVERSE will
> prune out that operation/component pair.
> 
> For LOAD-OP, the situation is trickier, whether LOAD-OP'ing a
> LOAD-ONLY-CL-SOURCE-FILE depends on a LOAD-SOURCE-OP or loads the file
> itself, a LOAD-OP will still be performed, and so subclasses and
> auxiliary methods will run, and so potential badness.


I'm sorry, I'm afraid I don't follow this.  If load-only-cl-source-file
is a subclass of cl-source-file, why would it be a problem that
subclasses and auxiliary methods will run?  Other subclasses of
cl-source-file won't have their methods run.  Are you concerned about
:around, :before, and :after methods on conventional cl-source-files
being inadvertently extended to interpreted-cl-source-file?  That does
seem potentially more problematic.

Does this tend to suggest that there should be a common supertype, say
cl-file that would have as children cl-source-file and
interpreted-cl-file, with some moving of appropriate methods up from
cl-source-file to cl-file?
> 
> I can think of a couple ways of dealing with the LOAD-OP case:
> 
> * make LOAD-ONLY-CL-SOURCE-FILE a subclass of SOURCE-FILE but not
>   CL-SOURCE-FILE.  This way, methods specializing on LOAD-OP and
>   CL-SOURCE-FILE won't get run for LOAD-ONLY-CL-SOURCE-FILE, but
>   generalized instances of LOAD-ONLY-CL-SOURCE-FILE won't
>   inherit behavior from CL-SOURCE-FILE.
> 
> * Add a protocol function, say, COMPONENT-DELEGATES-TO, which TRAVERSE
>   can use to substitute one operation/component pair for another, and
>   have a method of this function specializing on LOAD-OP and
>   LOAD-ONLY-CL-SOURCE-FILE that returns a LOAD-SOURCE-OP and the
>   component.  (This function would be similar to COMPONENT-DEPENDS-ON,
>   except that whereas C-D-O means "do that in addition to this", C-D-T
>   would mean "do that instead of this".)  This way, the LOAD-OP won't
>   be present in the traversal, but maybe this will make the operation
>   protocol harder to understand than it is already.
> 
> Any thoughts?

Maybe we need to think about the class structure.  Possible claim:
interpreted files (like interpreted-only cl files and things like shell
scripts) are simply different in that they are not "source" in the same
way as files that are transformed by compilation.  If one feels that
this claim is correct, then it suggests that the files-to-be-compiled
and the files-never-to-be-compiled should each go their own ways fairly
close to the top of the class hierarchy.  That is, the kinds of things
one would do for a shell script have a some things in common with the
kinds of things one would do for an interpreted cl file...

I'm not sure that this is entirely correct, since cl files have an
existence after loading but potentially before executing, that
conventional scripts don't have...


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV