Preliminary analysis of existing ASDF practices
in [Lisp]
|
Prev: Is LISP divine?
Next: keywords & macros
From: Juanjo on 13 Apr 2010 11:38 .... and some ideas about the future. Some of them affect how existing systems can be integrated with a particular implementation, ECL, but I hope you will be able to see beyond that. http://tream.dreamhosters.com/tream/musings/49-lisp/76-analysis-of-existing-asdf-files Comments better here at comp.lang.lisp
From: His kennyness on 13 Apr 2010 13:32 Juanjo wrote: > ... and some ideas about the future. Some of them affect how existing > systems can be integrated with a particular implementation, ECL, but I > hope you will be able to see beyond that. > > http://tream.dreamhosters.com/tream/musings/49-lisp/76-analysis-of-existing-asdf-files > > Comments better here at comp.lang.lisp Looks good. I did not see anything about the whacky choice by default not to load anything until everything is compiled, forcing endless declarations of dependencies 98% of which are achieved just by ordering the files a certain way. There are other bad choices all over ASDF. Is it worth saving? Is mk:defsystem in better shape? kt
From: Juanjo on 13 Apr 2010 14:27 On Apr 13, 7:32 pm, His kennyness <kentil...(a)gmail.com> wrote: > There are other bad choices all over ASDF. > Is it worth saving? Is mk:defsystem in better shape? If you have a look at the topmost table, I analyzed 291 distinct packages from two popular distributions (libcl and clbuild), plus some others I analyzed by hand. The question is whether we can and should move all that software to an orthogonal model. I believe we do not need something completely different. We may progressively introduce back some rationality into ASDF, making it closer to mk:defsystem but keeping the extensibility -- it is for instant intereting to be able to introduce new kinds of components, in particular for interfacing with other languages (fortran, C, etc). I started this discussion at the ASDF mailing list, but only to learn that is the wrong forum: just four people talking, some of them actually do not caring about other implementations or build models. What I would like to learn is what people think they have learnt that ASDF does wrong, things it gets right and to what extent the Common Lisp community is willing to accept any progress along one or another direction.
From: Faré on 13 Apr 2010 15:56 On Apr 13, 2:27 pm, Juanjo <juanjose.garciarip...(a)googlemail.com> wrote: > On Apr 13, 7:32 pm, His kennyness <kentil...(a)gmail.com> wrote: > >> There are other bad choices all over ASDF. >> Is it worth saving? Is mk:defsystem in better shape? > > If you have a look at the topmost table, I analyzed 291 distinct > packages from two popular distributions (libcl and clbuild), plus some > others I analyzed by hand. The question is whether we can and should > move all that software to an orthogonal model. > > I believe we do not need something completely different. We may > progressively introduce back some rationality into ASDF, making it > closer to mk:defsystem but keeping the extensibility -- it is for > instant intereting to be able to introduce new kinds of components, in > particular for interfacing with other languages (fortran, C, etc). > > I started this discussion at the ASDF mailing list, but only to learn > that is the wrong forum: just four people talking, some of them > actually do not caring about other implementations or build models. > > What I would like to learn is what people think they have learnt that > ASDF does wrong, things it gets right and to what extent the Common > Lisp community is willing to accept any progress along one or another > direction. > I am the current de facto ASDF maintainer. I became so shortly after I blogged myself into it. http://fare.livejournal.com/149264.html My objective with ASDF 2 was merely to package all the progress that happened since various versions of ASDF 1 previously spread to various Common Lisp implementations and distributions, clean up the current ASDF, make its interface more portable, and make it upgradable, configurable and releasable so that further development become possible. Another side objective was also to introduce some configuration mechanism which I could share with XCVB and which I hope would become universal amongst Common Lisp build systems. Amongst the strong constraints of ASDF 2 was that we should be 100% backwards compatible, especially since ASDF 1 users have no means of matching their system definitions to ASDF versions. The ASDF mailing- list is indeed NOT the place currently to seriously discuss changing model. However, once ASDF 2 is released, and thanks to its better ASDF versioning, it is not unconceivable that a future ASDF 3 should introduce incompatibilities allowing for a better build model. That said, I am also the author of XCVB, and I believe that it provides a better starting point for developing a new, incompatible, build system for Common Lisp. Unlike ASDF, it is not predicated around the "load, load, load and dump image model", but around the "load and compile, load and compile, and link model" that should appeal to ECL hackers. XCVB currently doesn't have a good extensibility story except "hack XCVB sources themselves". Sorry about that. I'd most welcome help designing an API. But XCVB also doesn't have problems with backwards incompatibility, it doesn't have the "all must fit in one file" limitation, the image-based paradigm, the confusion between build-time and run- time, the ambiguity and non-determinism in what side effects have or haven't happened before any given file is compiled or loaded, etc. All problems that you'll have a hard time removing from ASDF. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If all values are relative, then cannibalism is a matter of taste. Leo Strauss
From: His kennyness on 13 Apr 2010 16:47
Juanjo wrote: > On Apr 13, 7:32 pm, His kennyness <kentil...(a)gmail.com> wrote: >> There are other bad choices all over ASDF. >> Is it worth saving? Is mk:defsystem in better shape? > > If you have a look at the topmost table, I analyzed 291 distinct > packages from two popular distributions (libcl and clbuild), plus some > others I analyzed by hand. The question is whether we can and should > move all that software to an orthogonal model. Lisp will live forever and soon rule the world, let's not feel we have to stick with anything let alone something as shot through with problems as ASDF. The beauty is Dr McCarthy's main contrib: code as data. Fix ASDF any way needed and then write one simple parser that can work off existing .asd files (with more or less hinting, perhaps). > > I believe we do not need something completely different. We may > progressively introduce back some rationality into ASDF, making it > closer to mk:defsystem but keeping the extensibility -- it is for > instant intereting to be able to introduce new kinds of components, in > particular for interfacing with other languages (fortran, C, etc). > > I started this discussion at the ASDF mailing list, but only to learn > that is the wrong forum: just four people talking, some of them > actually do not caring about other implementations or build models. > > What I would like to learn is what people think they have learnt that > ASDF does wrong, things it gets right and to what extent the Common > Lisp community is willing to accept any progress along one or another > direction. Gets right? I hear it handles different lisp implementations effectively. kt |