On Wed, Mar 31, 2010 at 3:46 PM, Robert Goldman <span dir="ltr">&lt;<a href="mailto:rpgoldman@sift.info">rpgoldman@sift.info</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Lisp development --- at least for people like me --- is primarily an<br>
interactive process, and this is why building and loading/executing are<br>
/inextricably/ linked.<br></blockquote></div><br clear="all">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.<br>
<br>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.<br>
<br>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.<br>
<br>What I am trying to say is that ASDF &quot;as is&quot; 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.<br>
<br>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.<br>
<br>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.<br>
<br>I strongly believe that both things can and should coexist.<br><br>Juanjo<br><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>