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 <[email protected] > <mailto:[email protected]>> 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 _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
