Preliminary analysis of existing ASDF practices
in [Lisp]
|
Prev: Is LISP divine?
Next: keywords & macros
From: o.jasper on 16 Apr 2010 19:05 Damn that last post of mine seemed so much shorter when clicking 'send'. @joswig, as i said, you could just add an action to list the dependencies. Or one could go the special-var-hooks route instead of the methods. With *depends-on*, and *file-hook* *system-hook*, let the default of *depends-on* be as the method i gave, and then: using http://www.lispforum.com/viewtopic.php?f=2&t=663&start=10#p4206 (defun get-plan (system) (nconcing (:into collected) (let ((*file-hook* #'nconc-it) (*system-hook* #'nconc-it)) (act-on system)) collected)) And i am sure there is a way to do this with the current methods too. So there is no dire situation that the action to get the list may differ from the plan list from the :get-plan action. So there is no reason to wait for the entire plan. Even if you'd want to weigh some kind of priorities in loading, that should be a matter of a threading library. I see no reason to think that executing a plan produced this way is a problem either. Just iterating the list in sequence would load/compile things in the correct order.(albeit impossible to thread it with such basic way of outputting.)
From: o.jasper on 16 Apr 2010 19:08 Should add that returning the plan if the action itself fails might be a good idea.
From: Juanjo on 17 Apr 2010 07:50 On Apr 13, 7:32 pm, His kennyness <kentil...(a)gmail.com> wrote: > 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. You do not need to declare all compile-time dependencies -- just use the serial option in which every file (loaded or compile) depends on all that precede it. And furthermore, whether things are compiled or not could be easily changed http://permalink.gmane.org/gmane.lisp.asdf.devel/1266
From: Mario S. Mommer on 18 Apr 2010 14:41 Tim X <timx(a)nospam.dev.null> writes: > Juanjo <juanjose.garciaripoll(a)googlemail.com> writes: >> An even better version would not need methods at all! What makes >> TRAVERSE so unpredictable is that class dependencies, method >> specialization, :around, :after, and other apparent niceties can make >> a developer blow everything up -- to name a few things, ASDF recently >> changed the way it specializes some methods and it broke ECL's >> extensions in various and really misterious ways. >> >> OO is nice, but it is a distraction in this camp. Oh oh, that's... heretical! :-) Seriously though, the problem is not OO but trying to cram everything in that dependency graph image which, it seems, simply is not a good metaphor as soon as you are doing something more interesting, at least not in its current version. > I agree and think this exposes one of the reasons we have the situation > we are in. To some extent, ASDF has been so powerful that the individual > has been able to do things which on one had can make their life easier > when you are only looking at a system from a single perspective, but > once you move out into a wider world of possibilities, things get too > complex to manage. (let me just interrupt to say that I think that the words being used in this discussion are signs of trouble: Control is to be imposed, policies are to be enforced, the power of the individual curtailed, etc) > Concise and clear definition of dependencies would seem to be > the most critical base requirement. I don't think that that is the problem. The problem is identifying what kind of thing depend on what, and I'd like to propose viewing actions with side-effects as the things, and the dependencies as being that what everybody calls a dependency anyway. For example, consider this very simple rule. "the compilation of 'file1.lisp' depends on 'macros.lisp' and 'packages.lisp' being loaded". ASDF and defsystem treat this as dependencies on files, and not dependencies on the actions themselves. Instead of saying 'file1.lisp' depends on 'macros.lisp' and 'packages.lisp', and then awkwardly saying how, it would be better to say these things in a straight forward way. ASDF and defsystem tried the former approach, and maybe it is time to try the latter.
From: Juanjo on 18 Apr 2010 17:21
On Apr 18, 8:41 pm, m_mom...(a)yahoo.com (Mario S. Mommer) wrote: > Tim X <t...(a)nospam.dev.null> writes: > > Juanjo <juanjose.garciarip...(a)googlemail.com> writes: > >> OO is nice, but it is a distraction in this camp. > > Oh oh, that's... heretical! :-) Yes, and it feels good. > Seriously though, the problem is not OO but trying to cram everything in > that dependency graph image which, it seems, simply is not a good > metaphor as soon as you are doing something more interesting, at least > not in its current version. There is no problem with the graph image. Makefile uses it internally and a lot of people learned to live with that "primitive" environment. ASDF can improve over it, though. > (let me just interrupt to say that I think that the words being used in > this discussion are signs of trouble: Control is to be imposed, policies > are to be enforced, the power of the individual curtailed, etc) Let's not get scared about any discipline. Libraries have to coexist and just allowing _anything_ is not ok, specially because not everybody is capable or has the capability of knowing how the extensions and additions she / he creates will behave in the future... I for example do not. ASDF needs an specification. It needs contracts for the extensions to obey: that they inform the system about the things they do and when they do it, and what it leads to (creation of files, reading other stuff, etc)... we will figure out along the way. Please notice that the reason why we need some control is because these libraries are going to be built in very different environments and with very different purposes: - Maybe in a Windows system where only an interpreter is available. - Maybe in a Linux with SBCL - Maybe using ECL to produce a shared library - Maybe with ABCL to be ran in some server If we have a formal, well defined specification of minimums, then this can be implemented with various targets in mind. If on the other hand one allows everybody to assume they are in any environment, packages can be created at any time without informing ASDF, libraries are loaded in the asd file without notifying the dependency, side effects take place in the asd file which are not propagated to the compiled files, or arbitrary methods are created which add dependencies on the fly, then ASDF will only work in a very narrow environment: that of always running lisp images that load all of it software, piece by piece. > ASDF and defsystem treat this as dependencies on files, and not > dependencies on the actions themselves. Yes and no: actions depend on files but actions may also depend on other actions (internally in the ASDF graph). It is just that this possibility is not exposed in the DEFSYSTEM grammar. I am very well aware of this situation and if you peek my previous emails that is why I introduced the notion of "rules" and makefile- style programming. > Instead of saying 'file1.lisp' depends on 'macros.lisp' and > 'packages.lisp', and then awkwardly saying how, it would be better to > say these things in a straight forward way. ASDF and defsystem tried the > former approach, and maybe it is time to try the latter. I do not agree with this. The current situation is ok for a library with a set of existing lisp files for one simple reason: one may come with a set of rules for "loading", "compiling" and the like, which may be ok for a lisp where things are loaded and ready to be dumped, but if I want to reuse your library for building a set of object files to be linked together in ECL then it is not going to work just as nicely. In this case, a simple declarative description with a fixed set of rules and different backends (SBCL, ECL, CCL, ABCL...) is a powerful thing. The problem, though, begins when one wants to have things that are not contemplated by the Common Lisp specification and by ASDF as it stands now: * Automatically generated lisp files * Automatically generated documentation * Binary files for other languages (C++, C, fortran) * Shared libraries in those languages * Dependencies of compiled files on the previous things * ... What we need among other things is the possibility to * Add rules that express how to create some of the elements that participate in a system * Create rules that are executed for certain actions (:install, :uninstall, ...) * Implement reusable components that we know how to compile and *LOAD*, but which use other languages Note that all this can not be done with arbitary, hand written CLOS methods: ASDF has to be informed about how to do those tasks declaratively so that it can incorporate the knowledge in other contexts, such as when building an executable instead of dumping an image. |