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
On Mon, Oct 17, 2011 at 9:58 AM, Juan Jose Garcia-Ripoll < juanjose.garciaripoll@googlemail.com> wrote:
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.
Related to this, I appreciate that also what is exactly missing in ASDF is _operations_ that have to be performed before or after some system is loaded / compiled / etc.
Operations should not be part of the ASDF file. If we didn't have ASDF what we would naturally do is group them in a file which is loaded before everything else (or sometimes after it), for preparation (and for cleanup), typically.
Thinking about the most general way to do it, which does not involve any methods whatsoever, and such that the whole system may also be loaded without ASDF, I think the best way would be to have some declaration such as
{:after | :before} (operation+) operation = (operation-pattern module-to-be-loaded) operation-pattern = {* | asdf-operation-class-symbol}
The syntax is reminiscent of :in-order-to for the module and the operation, and it only differs in the time in which it is performed.
I believe this very much solves all the problems listed so far. It also has some advantages over explicit lisp forms, for it avoids problems with non-existent packages at the time of reading the asdf, and it also generalizes to all operations.
I also insist that having the operations being actually stored in files makes it relatively easy to map an ASDF to a set of load statements, making the library rather independent of actual ASDF complexities.
Juanjo
: 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
On 10/17/11 Oct 17 -3:58 AM, Juan Jose Garcia-Ripoll wrote:
2011/10/17 Gábor Balázs <gabalz@gmail.com mailto: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 sympathize with this, but I guess I also wonder how feasible this goal is, and whether we will break the world trying to reach it.
ASDF was a step beyond DEFSYSTEM, because it permitted extensibility through the use of CLOS. If one wants to do away with extensibility by CLOS, I'm inclined to say that's the job of XCVB or some other ASDF successor.
I think it's a worthy goal, but I don't think it's the ASDF goal.
At some point this becomes like trying to create a declarative version of "make." It's a worthwhile goal, but it should be something else --- trying to smoothly deform "make" into a declarative thing isn't a feasible goal. There are discontinuities on the way.
Remember "the better is the enemy of the good"!
best, r
-
Faré -
Juan Jose Garcia-Ripoll -
Robert Goldman