good evening;
On 2010-03-31, at 19:25 , Juan Jose Garcia-Ripoll wrote:
On Wed, Mar 31, 2010 at 3:46 PM, Robert Goldman rpgoldman@sift.info wrote: Lisp development --- at least for people like me --- is primarily an interactive process, and this is why building and loading/executing are /inextricably/ linked.
Please note that image driven development is NOT the only paradigm that exists in the lisp world. ECL works very well at creating standalone executables from compiled files, but it can not dump binary images of its full environment because that can not be implemented portably across all platforms we support -- specially not when one mixes shared libraries, different memory management paradigms (C, lisp, C++, operating system) and other stuff.
in general, "image-driven" development does not preclude a release which comprises more that one file, but if you were more specific about requirements, it would be easier understand where the problems arise for ecl.
The problem is that people who are used to think on image driven development are those who have pushed forward also the development of ASDF as it is right now and indeed, with this mentality of an image where everything is loaded there is no distinction between placing things an the *.asd file or in the compiled files.
this sentence implies either a contingent development or a logical consequence which issues from "image driven development". my experience contradicts the former and logic does not support the latter.
In other words, the flexibility has propagated to the users with an absolute lack of organization in how things are done right now.
yes, one finds among asdf users programmers who have not taken care to make worthwhile distinctions. their practice is not inherent in an "image-driven" development paradigm.
I even found out some libraries that ave problems in the dependencies, because the image driven development has side effects, such as the creation of macros, etc, which persist beyond compilation and can lead the developer to think that a load-op succeeds when it will not in a fresh new image.
then they were sloppy. even in "image-driven" development one must attend to the various environments. the distinction between and the consequences of source-only, binary-only, and mixed builds is not arcane.
What I am trying to say is that ASDF "as is" need not stop working. We may keep ASDF as a large database which you can use to power interactive development and automatic recompilation as things change. I believe this is a wonderful feature it is implicit in the long email I wrote.
However, ASDF has to seek other fields and in particlar enforce a discipline such that existing systems can be built from scratch using different paradigms -- for instance, building standalone programs from individual components.
In other words, the image-driven system can not be the model on which ASDF is built and it can not be part of its semantics because it prevents other models, but it has to remain an option for those who want to use it.
you assert a logical necessity for which i do not share your experience. you will need to argue that with more examples and more care before i can follow it.
as i have been able to comprehend the implied requirements for ecl's delivery use cases from the messages in this venue, while they do extend beyond asdf's present abilities, i have yet to have read any which are at odds with the (limited) dependency-directed mechanics at asdf's core.
yes, strictly declarative system definitions would be good. i posted a note some time back which discussed the changes to asdf which i observed to be sufficient to handle the population of .asd's in the wild with limited exceptions.
there was a concern expressed that a program be able to locate components at all stages in its life-cycle. the concern predates asdf. the mechanism to accomplish it as well. they can be integrated with asdf, used along side it, or used independently. it is demonstrably possible to do any and all.
neither of these issues is necessarily related with a "image-driven" development paradigm.