2011/10/17 Gábor Balázs
<gabalz@gmail.com>
Hm, I like the idea of having multiple classes for cl-source-file objects. But I wouldn't do it through CLOS.
I tend to agree on this, for CLOS is not declarative. It would become very hard to automatically deciphering defsystem files, and what they do.
I also believe that the wrap-around functionality does not have to be that general. In particular this is specifically required only for _compiling_, not for loading. I would not want an :around semantics to exist at all for loading, because that would completely eliminate any possible and future goal of making ASDF ship pre-compiled libraries.
Out of the tasks listed here:
locally renaming packages
binding *readtables* and other syntax-controlling variables
handling warnings and other conditions
proclaiming optimization settings
saving code coverage information
maintaining meta-data about compilation timings
resetting gensym counters, PRNG seeds, etc., for determinism
cheating the source-location and/or timestamping systems
checking that some cleanup function was properly called
etc.
I see nothing that could not exist in :eval-when forms. The problem is thus not that these operations may live in the compiled files, but the fact that we need them to be executed every time the files in the system are compiled.
In a sense, it is a _reversed_ dependency. Normally we have that file2 depends on file1 and thus file2 is loaded _after_ file1 is loaded. Couldn't we just add another component to defsystem which is loaded when _any_ file is to be changed? It would be like a prerequisite module or file.