Dear Robert, >> failing test(s): test-configuration.script test-multiple.script >> test-static-and-serial.script test-utilities.script > > OK, seems like exiling functions to ASDF-UTILS and no longer exporting > from ASDF is causing this failure. > Oops. I've fixed the tests to work despite utilities not being exported anymore.
> Question: what's the removal of these exports doing, aside from > assuaging a feeling of tidiness? I get it that one might not like > people using ASDF as a source of utilities, but is that not-liking > strong enough to break existing code (or in this case, re-breaking > code)? > I don't have a strong opinion on that. Apparently, Xach has one, and I care about his opinion a lot to improve the adoption of ASDF and other Lisp utility packages. > [Faré, your ILC 2012 stuff looks like a lot more exciting place > to spend hours than tidying ASDF!] > I think so, too, and I've made significant progress in the last few days: working transformation from interface-passing style to traditional OO style, and now the beginning of actual description of the software in the article, rather than just a plan. Hopefully, the final paper will be ready by the deadline of the 25th. > I also get it that Xach doesn't like use of ASDF as a utility source for > Quicklisp, because it introduces a dependency on bleeding edge versions > of ASDF. But that doesn't seem to me to be a problem with use of ASDF > for utilities per se --- the problem instead is that ASDF doesn't have a > stable API[*]. Maybe instead of refusing to export these utilities, we > should do a feature freeze, and defer future API changes (any changes to > exported symbols) to ASDF 3, which may or may not arrive before the > coming of the programmer's choice of Messiah. > > Freezing the API would also have the effect of encouraging the > development of alternative sources of utility functions. As people want > more functionality, they will be driven to develop it in a freestanding > library, and that will naturally motivate them to move away from using > ASDF as a utility source in favor of a new library that does not have > ASDF's special status. [As I read it, one of Xach's objections to the > use of ASDF as a utility source is that it has a special status. This > seems an eminently reasonable ground for objection.] > > Best, > r > > * There is a separate problem that people might like to see ASDF wither > away, but I'd be happier to postpone preparations for said withering > until it is sooner to come. The better is the enemy of the good, and > all that. > Frankly, I agree that Xach indeed is both a bit early in wanting to move away from ASDF without a clear universal replacement in sight (and I regret to admit that XCVB isn't ready yet as such a *universal* replacement). I also believe that Xach is being overly conservative in his reluctance to upgrade to the "bleeding edge" of asdf *releases* while having software depend on the often unreleased bleeding edge of about everything else (including asdf-utils). But I'll do whatever makes Xach happy, because he's the one who's having the best CL software distribution so far (the only one with actual end-users, it seems). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, strictures, though they bind, Strangely liberate the mind. _______________________________________________ asdf-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
