And class 0 could be the (unspecified) default.
However, I would still prefer to have some kind of simplified notation for the local package renaming functionality as I think that is the most common.
And I have no idea how difficult it is to put something like this into asdf as I am not familiar with its code...
> I have my function, which does the described job for me too. The point here
> is to offer this functionality in public on an easy, standard way.
Agreed.
> Personally, I like to have a single defsystem sexp in the asd file, so I
> would prefer avoiding function definitions there.
Same here. However, I would even more prefer having one generic mechanism
for all these similar issues (wrapping bindings and environment-setup
side-effects around compilation), rather than every time having to invent
a new ad-hoc mechanism for each possible binding or side-effect that one
might conceivably want:
locally renaming packages
binding *readtables* and other syntax-controlling variables
handling warnings and other conditions
proclaiming optimization settings
saving code coverage information
maintaining meta-data about compilation timings
resetting gensym counters, PRNG seeds, etc., for determinism
cheating the source-location and/or timestamping systems
checking that some cleanup function was properly called
etc.
> However to do that nicely, asdf should be refactored in a way
> described by Robert.
Not necessarily.
It is often important to wrap code around compilation, as shown above,
but after writing XCVB, it seems to be that it isn't so useful
to have wrappers around subtrees of the build, unless you can somehow
save the information to files after a build, and merge it from saved
files when you skip the incremental compilation of a file that hasn't
been modified. In other words, all the information should be inside
the FASL or a complement to said FASL. Otherwise, whatever information
you use is just going to make your build less deterministic,
and you'll end up always building from clean anyway, at which point
you might as well use a load list instead of asdf.
> But I think it would be still nice to offer this
> (cheap) renaming functionality separately without some heavy syntax
> (wrapping the whole defsystem into a function seems to be heavy for me).
>
A more interesting question would be:
why not do that as originally intended,
by defining a proper CLOS subclass of cl-source-file?
If it isn't fully satisfactory, what would be,
and what variant of CLOS would it take?
(Say, would SHEEPLE make things nicer?)
> it is fairly easy to implement into the current mainstream asdf version
> it is easy to use, so CL library developers could easily eliminate the
> :nicknames options from the package definitions and use this instead (they
> should basically change only a few lines of code in the .asd and
> package.lisp files)
> unfortunately, it is not the most general solution, so the arbitrary
> function wrapping would not be provided this way
>
> I feel the 2nd point very valuable, so I think it would worth doing...
>
Voting for liberty is like raping for virginity. — Jim Davidson