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.
Juanjo