On 8/31/10 Aug 31 -2:03 PM, Faré wrote:
On 31 August 2010 12:55, Nikodemus Siivola nikodemus@random-state.net wrote:
On 19 August 2010 22:04, Faré fahree@gmail.com wrote:
Exporting random internal utilities from ASDF is a terrible idea, IMO.
The utilities are not completely random. I use them, and other people use them.
People will use them, and then you will be oblidged to maintain them even when you decide that they're not what you wanted.
That's the whole point. I want to be able to (require :asdf) and then use (asdf:getenv ...) to configure things. Not have to reinvent merge-pathnames* or pathname-directory-pathname or split-string or truenamize. As for aif and appendf they were singled out before my time and I don't think there's anything wrong with them. Should I stop exporting them? Possibly. But why? I don't have a strong opinion.
They also pointlessly pollute the namespaces of clients who use ASDF.
One man's "pollution" is another man's "great stuff".
In any case, just as for any other package, if you (:use :ASDF) instead of using ASDF:... prefixed symbols or (:import-from :ASDF ...) them one by one, you accept that you'll get whichever symbols ASDF will export in the future. You get what you ask for, and ASDF will not stop changing just because of you.
(It doesn't personally bother me, but it just seems wrong on pretty much every level.)
I agree that namespace management in CL is wrong on pretty much every level.
I'd just like to amplify Faré's response in one way. The internal utilities are really not random. One of the things discovered in the course of building ASDF 2 (and cemented, for me, in the process of writing an ILC paper about it with Faré) is the complete inadequacy of CL pathnames for portable operations.
Pathname-wrangling is very likely something that an ASDF system definer --- and even more an ASDF system extender --- will need to deal with. So functions to operate on them are a critical tool that ASDF must supply. Indeed, file and directory access in general is not adequately supported in a portable way. Similarly, in order to make it possible for ASDF extenders to process new types of components, we need a portable version of something like RUN-SHELL-COMMAND, and this cannot be supplied /to/ ASDF, it must be supplied /by/ ASDF.
Now, arguably people who are simply going to define simple ASDF systems should have a simple API, which means a package that exports only the minimum necessary set of symbols. This would have to be complemented by a "fatter" API. However, this correspondence started with an objection to defining multiple packages/multiple APIs. The necessary consequence of this objection is that there will be a single, fat API, and more, rather than less, namespace pollution. [For the record, I would have preferred a thinner set of ASDF exports, accompanied by a utilities package or set of packages.]
Finally, because of how central ASDF is to the CL community, I don't believe that we should repair previous namespace pollution. If something has in the past been exported from ASDF, it should almost certainly continue to be exported, even if it's something like APPENDF or AIF, that is pretty clearly inappropriate. That namespace pollution has already happened, and breaking existing systems to fix it would be inappropriate.
Best, r