Prev: Is LISP divine?
Next: keywords & macros
From: Mario S. Mommer on 15 Apr 2010 16:15 Juanjo <juanjose.garciaripoll(a)googlemail.com> writes: > It may just as simple, but some people believe it should be more > complex. > > 1) Dependencies should be different depending on the "action". That > complicates things quite a bit. > 2) Some actions trigger other actions (:compiled -> :load or :load - >> :compile). That is even more complicated. ....right. IMO it is better to write an ad-hoc loader with a good library to asist, and conforming to a realistic and practical set of best practice guidelines. The complicated cases of system definition are best handled programatically anyway. At least it is more natural. > > All this complexity, which does not exist in defsystem, Are you sure? IIRC defsystem is fully extensible.
From: Juanjo on 15 Apr 2010 16:56 On Apr 15, 10:12 pm, m_mom...(a)yahoo.com (Mario S. Mommer) wrote: > Here's something on the lines of what I have in mind: > > (load-module "src" > (load-file "file1" > (load-file "file 2")) > (load-file "file3")) > > where load module would append the directory "src" to some special, and > the load-file would be implemented in a lazy fashion. That does not look much simpler to me, specially when you look around for the kind of dependencies that people are writing, where C, D and E depend on A, D depends on A B and C, E depends on D an some other module, and the graph gets rather complex. I just wonder, like you do, to what extent this all makes sense, other than to enhance the parallelizability of the build process -- one of the goals of XCVB and something apparently valued at ITA. The real problem, though is the other thing you pointed out: when some of the operations needed to build the system depend on components of the system itself. Say for instance that I implement a compiler and the first three files A B and C implement a first simplified version and the other ones are built with it, D E and F. How do you write such a thing? We have to write rules, and that means extending ASDF in the complicated way it provides us, and we find compilcations such as the fact that those rules must use symbols which are defined in the files A B and C. From a conceptual (not yet implementation) point of view I am toying with a declarative extension to ASDF, adding kind of makefile-type rules. The idea would be something like what I show below. Instead of tinkering with methods and so on, we provide some kind of pattern matching that produces code (code is not evaluated, but concatenated) which may rely on some macrolet forms, by which ASDF provides most of the information: where to place files, etc. By placing the package file in the :asdf-support we allow the rules to depend on the rest of the system. By storing the rules as just S-expr, not lisp code, we allow the code to work once the appropriate dependencies have been loaded. In addition to this, rules may be installed by other extensions (say a hypothetical cffi-asdf tiny module) and the ASDF files remail purely declarative -- no more side effects than package definitions. mysystem.asd: (defsystem :my-system :asdf-dependency ((:file "package") (:file "mysystem.asd")) :components ((:file "package") (:file "A") ... (:file "D" :depends- on "D-dsl" "A" "B" "C") ...)) ;;; ASDF would stop reading as soon as it reaches one defsystem form ;;; The following is loaded as part of the :asdf-dependency, ;;; since it is loaded _after_ "package" we have the package ;;; available here. (def-asdf-rule (:my-system :file "D") (my-system:generate-file (asdf:output-file) (first (asdf:dependencies))))
From: Juanjo on 15 Apr 2010 17:05 On Apr 15, 10:06 pm, Nathan Froyd <froy...(a)gmail.com> wrote: > This is the big sticking point in switching to something else. There > are good reasons why side-effectful bits are useful in an .asd file. > Custom component definitions and specializing operations on those components > are what come immediately to mind I argue that this can be done in a "declarative" manner. That would be ok because it would also impose a stricter syntax and we can enforce further requirements. > > * Restrict the set of operations that ASDF supports to a few: compile, > > load & test > > Please don't do this. There are very good reasons to support more > than three operations on a system; I've written at least two custom > operations for my own personal use (building tar files and autogenerating > documentation); I'm sure you can think of more. Answer this: assume that ASDF becomes a library and can provide you with an annotated graph with all the components of a system, topologically sorted, each one futher annotated with the files it produces. Do you really need then the current system that ASDF has or wouldn't it suffice to just traverse the list, a-la MAPC, with a function that creates a tar file? The problem is not extensibility, but that ASDF right now is so confusing that it does not allow people to realize there are other ways to do things than with methods. Simplifying the set of operations would allow creating the previous graph in a simpler form: one graph for LOAD and one graph for COMPILE, the former one being the one you actually need because it lists what a running image needs -- compiled files, documentation, etc. > > * Simplify the way components are written, perhaps adding some > > syntactic sugar. > > * Create an API to load and traverse the set of systems and their > > dependencies. > > This would be something useful standalone; coaxing a list of files out > of ASDF can be an exercise in frustration. Doubly so if you want > system-relative names. This is precisely what I meant and what jasper so clearly exposed: ASDF is just a hidden database of dependencies. We only need to provide a clean mean to expose those dependencies and make them as simple and well specified as possible > > * Replace the routine that drives ASDF, TRAVERSE, with something > > everybody understands. > > Method combination would be a good start here. TRAVERSE was written > the way it was because of poor CLOS support from some implementations. 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. Juanjo
From: Jochen Schmidt on 15 Apr 2010 18:34 On 2010-04-14 00:29:34 +0200, Juanjo said: > That said, I have read XCVB's manual and I feel it introduces an > unneeded level of complexity in it all. Parallel compilation is nice, > but forcing the use of makefiles, permitting the developers to scatter > the dependencies of their software over different files, and relying > on external drivers, plus the size of the software itself -- ASDF > could and should be so lean! --, does not really convince me. That was also my feelings when I investigated it. I quickly came to the conclusion "XCVB" must stand for "Xtra Complicated Variant of a Buildsystem". Actually I think the idea behind XCVB is good, but I fear that the majority of lisp projects do not face the complexities which triggered it. More, I think a successor to what ASDF provides today should really be as simple as possible. A separation of concerns would certainly a step in the right direction. A system in its minimal core doesn't need any inherent facilities to build it or install it or package it - it should only be a straightforward description which allows others to implement stuff like building, installing and so on ON TOP of it. It should be readable by lisp but NOT mandate a complete implementation of CL to interpret it. It shouldn't even be mandatory to write system descriptions by hand - there could easily be generators and IDE support to do this. To me the most simple form of a system consists of a set of CL components, their dependencies and the external dependencies to other systems. Jochen -- Jochen Schmidt CRISPYLOGICS Uhlandstr. 9, 90408 Nuremberg Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83 mailto:(format nil "~(~36r@~36r.~36r~)" 870180 1680085828711918828 16438) http://www.crispylogics.com
From: o.jasper on 15 Apr 2010 18:45
Note: in the linked lisp file, there are two mistakes in (def-a- system :t..) (that is why it doesn't load) You can do anything with dependencies with the given libs, including calling different actions back and forth. Compiling/loading would be something like this: http://www.ojasper.nl/src/lisp/dep/compiler.lisp I guess one could even make a package to make loader/compilers with this, showing the files in the correct order to some loader/compiler. Note that my approach is from 'first principles'; being that if you need to build something that depends on something, you need to get what it depends on first. And that you might need to store stuff about it during, like where you put the compiled result, whether it is compiled, whether it is loaded. Apply experience onto first principles. That is how physics works, the first principles being postulates, and experiments and measurements being 'experience'. Why? History is a cludge, but it is all the data you have, however, first principles are simple! So find a way to combine them. Somewhat like in the horses joke like here http://www.silvers.org/GenEngineering.html (just a random link, those jokes are repeated all over.) I don't mean to imply any sort of dismissiveness of the data, Juanjo, this really is something that needs attention, and it is good to have a list of projects that misuse asd files. Not sure that i'd consider two Defsystems in an asd file an error.(Well, seems like asdf doesn't read in both, but hardly much of an issue in-principle if it would.) I don't think regular users should be doing anything else but fill some kind of Defsystem form, no defmethod-ing or anything like that. |