[asdf-devel] The future of ASDF (was logical pathnames)

[james anderson]

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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100331/21ab58ea/attachment.html>