LispForum

... 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/mus ... asdf-files

Comments better here or at comp.lang.lisp

I dont get what we want extensibility for. I mean, if we can clearly specify it's purposes, and they can they be served, why allow people to complicate it?

I'd say, just make it a dependency, loading and compilation tool. Consider stuff like testing, autodocumentation, maybe even conversion of the readme to be various special stuff to load, where the files loaded might have their little depencies, pretty much exactly as adding (defsystem :project-name-test ..) (defsystem :project-name-autodoc ..) would behave except allowing one to add secondary component-set with various names, and conventions :test, :autodoc, :readme, perhaps :first-time. And then just deny any other stuff in the .asd files.

What exactly can't you do just with loading files? Nothing afaics, correct me if i am wrong..

Btw, i tried to poke information out of asdf, but ended up just scanning the .asd files themselves.. Perhaps just allow reading like this: (system-part system part-name-exactly-as-in-defsystem) Edit: xcvb sounds interesting, and an bunch of important points, like failures in loading need to be clear.

Jasper wrote:I dont get what we want extensibility for. I mean, if we can clearly specify it's purposes, and they can they be served, why allow people to complicate it?

I do not think 100% extensibility is ok, but people are building Makefiles and other flexible build systems out there and they are still able to build and install their C and C++ libraries without problems. Extensibility is not the problem, but the lack of verifiable rules.

I consider extensions may be really useful. Suppose at some point CFFI becomes powerful enough to drive the process of compiling and loading shared libraries. Or suppose we create plug-in components for doxygen documentation. All that has been rationalized and used in the Unix world. I believe this can be done equally well in the Lisp world without having to manually write Lisp scripts that drive all this.

Jasper wrote:I'd say, just make it a dependency, loading and compilation tool. Consider stuff like testing, autodocumentation, maybe even conversion of the readme to be various special stuff to load, where the files loaded might have their little depencies, pretty much exactly as adding (defsystem :project-name-test ..) (defsystem :project-name-autodoc ..) would behave except allowing one to add secondary component-set with various names, and conventions :test, :autodoc, :readme, perhaps :first-time. And then just deny any other stuff in the .asd files.

The problem is who maintains the set of valid extensions and how to process them. For instance, say I come up with the above mentioned rules for C files in my super-great F-FFI library and CFFI also develops its own. Who gets the right to have a :shared-library rule? Most important: who and how maintains the associated code. ASDF? The F-FFI and CFFI developers?

Jasper wrote:Btw, i tried to poke information out of asdf, but ended up just scanning the .asd files themselves.. Perhaps just allow reading like this: (system-part system part-name-exactly-as-in-defsystem) Edit: xcvb sounds interesting, and an bunch of important points, like failures in loading need to be clear.

Current syntax is ok. ASDF simply can not help you in parsing ASDF files because it has to load those files using LOAD and they are full of side effects: that is the reason why there is no API to inspect system dependencies. Clearing all the clutter in those files would be a great step towards better automation of Lisp software distribution, plus a great help in creating safety and sanity checks of to-be-built software.

Edit: a much more clearer reply is in comp.lang.lisp.

jjgarcia wrote:I do not think 100% extensibility is ok, but people are building Makefiles and other flexible build systems out there and they are still able to build and install their C and C++ libraries without problems. Extensibility is not the problem, but the lack of verifiable rules.

jjgarcia wrote:Suppose at some point CFFI becomes powerful enough to drive the process of compiling and loading shared libraries.

Hmm i saw it as a 'linked todo graph', where different things to do are in done different files. Like a graph how things depend with functions(files) along the way that actually do it.

But i kindah missed that the files are actually objects from which these functions are to be created, not the functions themselves. And then each different function has it's own dependencies. Something like (dosomething-depends-on what file/system), (dosomething what file/system) with the things to do; 'what'; being :compile, :load, :compile-test, :test, or if it were cffi-driven :ecl-to-c :cffi-compile, :cffi-load, and various autodocs :doxygen-autodoc. Maybe even :benchmark-test. Perhaps one would want extensions like this to be able to choose them what to do if a dependency is missing aswel.
Edit: but with this extensibility, i expect it to be used. The basic load, compile and such should of course then also be in terms of the extensibility, in it's own little package.

I don't think regular projects which don't have their purpose to serve people something for asdf should do anything with extending. Infact, perhaps asdf should spy on *package*, and warn them if defsystem and extending is done from the same package, or it could put stuff in a package :asdf-extend.

You misread and i (moreso) miswrote my last paragraph. I meant 'reading' as-in accessors/reader methods. Just that there is a generic function: (defgeneric get-system-keyword (system keyword)..) Just getting the data behind keywords like :description etcetera.

Edit: having operation :test-op goes right against this idea, i think it would be better to allow stuff to have entries, and have something like :test (:components ..
:run-components ...) and then :compile-test, :load-test :do-test as operations. Tests can then fail with ERROR, ASSERT, WARN, and such, right? Not to say my way is the only way.. Edit: ok, you could see it as adding another way to add 'files', but it leads people in the direction of extending it, when they imo shouldn't be.

As another data point: I have trouble using ASDF , because it uses define-method-combination etc., which are not defined in Corman Common Lisp. I also use CLISP, but I use Corman Lisp more. There were patches by Edi Weitz to make previous versions of ASDF work with Corman Lisp, but the new version of ASDF uses method-combination...

My own thoughts/comments: I would love to add the missing functionality to Corman Lisp, but I would strongly suggest that ASDF would benefit greatly by simplifying/shrinking the amount of the standard that it uses. Imagine if ASDF only used basic Lisp functionality. It would be in a good position to be used by a much larger pool of Lisp implementations (including much younger implementations). The ASDF users and ASDF implementers would both benefit from that. Also, as a thought experiment, imagine that I write a little library to patch up lisps deficient in the CLOS area of the ANSI standard. I wouldn't be able to use ASDF to deliver such a library.

I think that sometimes the functionality needs to be considered separately to the implementation, or perhaps the key functionality should be specified (call it a design document, or a written goal, or whatever, but it should be short - one, maybe two pages at the most) and then coded to. This has the benefit of the documentation being half written.