On 3/31/10 Mar 31 -12:25 PM, Juan Jose Garcia-Ripoll wrote:
On Wed, Mar 31, 2010 at 3:46 PM, Robert Goldman <rpgoldman@sift.info mailto: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.
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. In other words, the flexibility has propagated to the users with an absolute lack of organization in how things are done right now.
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.
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.
I strongly believe that both things can and should coexist.
With all due respect, this seems contentious and unsupported. I don't see any particular reason to believe that a tool for the coherent maintenance of a long-running image would also be a good fit for more conventional development.
There are already tools for the non-image-driven development. If ECL is not aiming at image-driven development, maybe a tool like make, or make + autoconf would be a better fit.
That said, if you wish to try to make ASDF work for conventional build-and-exit system construction, and that doesn't break ASDF for image integrity maintenance, more power to you!
Best, R