: Juanjo
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 do not like the way that ASDF is currently extended. But I don't have anything better to offer. XCVB tries to have built into it all the things that ASDF extensions are usually used for, and some more things not well done by ASDF (such as conditional compilation); but the way XCVB is currently extended is worse, if anything, than the way ASDF is currently extended. I've been brainstorming with Peter Keller on how to do better, but so far we haven't gotten any implementation out of our ideas.
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.
Exactly. In the context of XCVB, a Makefile, etc., you build object files (fasls), then you link them, but you don't want any complex wrapping around the individual linking of each file.
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.
Binding variables (as opposed to setting them)? Handling conditions? I don't want my whole file in an eval-when, and what more I'd lose toplevelness of forms! Checking that the eval-when's are balanced and/or that a cleanup form is called? I don't want to manually insert the cleanup form at the end of every file, or to use sed or perl to check that the form is indeed present (see molicle). Setting the PRNG seed from a checksum of the dependencies? That's a job you can't do without help from the build system, anyway.
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.
I'm not sure what you mean. At this point an example is welcome. What you say reminds me of gwking's asdf-system-connections (which BTW I think was a bad idea, because it makes the semantics of a system more context-dependent than it should be).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Cubans bemoan the three failures of the revolution: breakfast, lunch and dinner