[asdf-devel] Should ASDF define many packages?

[Robert Goldman]

On 8/31/10 Aug 31 -2:03 PM, Faré wrote:
> On 31 August 2010 12:55, Nikodemus Siivola <nikodemus at random-state.net> wrote:
>> On 19 August 2010 22:04, Faré <fahree at 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