"The best is the enemy of the good." --- Voltaire
There seems to be a strong sentiment from at least part of this mailing list that ASDF loading should be reorganized so that some minimal core functionality is loaded, and more can be loaded on demand.
I'd like to go on record as opposing this. I see the arguments for tidiness involved, but I think there are some powerful arguments against doing this:
1. It raises the bar for ASDF novices. Every line we add to a lisp init file is a huge cost, from my point of view. I'd prefer we kept it to (require :asdf).
2. It makes testing more complicated. In order to be confident that code works properly, we will now have to test it in a number of configurations that will grow exponentially with the number of modules to be loaded. If we have a relatively big core, we can get away with one run of the test suite per lisp implementation X platform.
3. Related to 2, it makes development of ASDF system definitions more tricky. Now, in order to write an asdf system definition, you will have to track which modules you have loaded, and which modules the eventual users of your system definition are likely to have loaded. You may have to modify your ASDF system definition so that it forces load of modules. This is deeply undesirable, IMO, since doing this is outside the declarative DEFSYSTEM core of ASDF.
4. It is effort that we do not have in superabundance. There are outstanding ASDF bugs --- simple bugs like tests failing --- that are not getting fixed. An exercise in refactoring and tidiness will take more of the lifeblood away from core development.
5. It will create a revision control system merge hassle. Restructuring means moving stuff back and forth among files. This will neatly foil diff and emerge. I had enough of that back when we moved to git. I still haven't recovered the work I did on implementing clean-op, and backporting from markdown to texinfo was a drag. This last is not critical, if the transition is made in one swift, well-scheduled cut-over.
Best, R
On Wed, 3 Feb 2010, Robert Goldman wrote:
"The best is the enemy of the good." --- Voltaire
So far, I have only written about pragmatically solved problems. Do you really want to hear what I think might be best? ;)
There seems to be a strong sentiment from at least part of this mailing list that ASDF loading should be reorganized so that some minimal core functionality is loaded, and more can be loaded on demand.
I'd like to go on record as opposing this. I see the arguments for tidiness involved, but I think there are some powerful arguments against doing this:
...
Compared to make or autotools or cmake or bjam or ... ASDF is very small in functionality, footprint, etc. Except for users having trouble finding docs, it is also rather easy to install.
Here's an approach that would make a lot of sense and solve numerous backward-compatibility issues. The full ASDF toolset may be big and hard to install [see below]. But a simple command drops a self-contained file customized for a particular system. Thus end users don't even have to install ASDF to use it!
This approach also solves the bootstrap issue -- users can bootstrap using the full functionality of ASDF. So it actually installs just like any other library.
- Daniel
P.S. Any similarity to the configure.ac -> configure transform is purely accidental. ;)
On Wed, 2010-02-03 at 23:07 -0500, Daniel Herring wrote:
On Wed, 3 Feb 2010, Robert Goldman wrote:
"The best is the enemy of the good." --- Voltaire
So far, I have only written about pragmatically solved problems. Do you really want to hear what I think might be best? ;)
There seems to be a strong sentiment from at least part of this mailing list that ASDF loading should be reorganized so that some minimal core functionality is loaded, and more can be loaded on demand.
I'd like to go on record as opposing this. I see the arguments for tidiness involved, but I think there are some powerful arguments against doing this:
...
Compared to make or autotools or cmake or bjam or ... ASDF is very small in functionality, footprint, etc. Except for users having trouble finding docs, it is also rather easy to install.
Here's an approach that would make a lot of sense and solve numerous backward-compatibility issues. The full ASDF toolset may be big and hard to install [see below]. But a simple command drops a self-contained file customized for a particular system. Thus end users don't even have to install ASDF to use it!
This approach also solves the bootstrap issue -- users can bootstrap using the full functionality of ASDF. So it actually installs just like any other library.
- Daniel
P.S. Any similarity to the configure.ac -> configure transform is purely accidental. ;)
Did you forget an attachment ?