Re: XCVB, a replacement for ASDF

Faré wrote:
> Dear Lisp hackers,
> 
> I know that it's a time when everyone is thinking about replacing
> ASDF, so here's my contribution to this maybe preposterous endeavor.
> I'd like to get your feedback on this write-up I made (attached) about
> this project I'm working on with an intern at ITA.
> 
> Also, if you know other people I should be talking to regarding this
> topic, or webpages or papers I should have read, please point me to
> them.

I apologize for being so late answering, but I have been writing lisp code!

I am intrigued by this proposal, and it leads me to consider some of the
areas where I have had trouble with ASDF.  I hope these are helpful:

1.  There is no way to wrap some actions around all of the operations
performed on a module; I believe that this is because we consider the
perform on a parent component to be done after the performs on all of
its sub-components

2.  The test operation's semantics are unclear.  What should happen when
one tests a component?  What is the contract the implementer should be
making with user of the test system?  Should the test operation hurl
errors?  It cannot return values.  Should it write output somewhere for
later inspection?  If so, where should that output be written?  Ideally,
we should find a contract that would accommodate the use of many
different testing frameworks.

3.  There is no way to make operations return values.  Maybe this is not
a problem, but there should be some way to get reports out of an
operation.  A problem with this is that anything ASDF writes may be lost
in gobs of compiler chatter.

4.  It would be nice if there were some clear relationship between
packages and asdf systems.  This relates to:

5.  The system definition should support documentation operations.

a.  The relationship to 4 arises because there are several documentation
systems that support documenting packages, and some that support
documenting ASDF systems (actually, I can only think of Gary's, which I
believe to involve having to do extensive groveling over the ASDF system
in question).  If the package/system relationship were clarified, that
might help.

b. Documentation operations should include at least generating
documentation *and accessing it*.  If one uses a system definition
system to find the source files, one should also use it to find the
documentation files.  Currently, it is quite possible that one can
easily load a system, but not be able to find its documentation without
unseemly rummaging through the file system.

6.  We should do something more intelligent with macros and other
constructs that affect compilation.  It should be possible for a system
implementor to say "if you recompile system A, you must recompile all
systems that depend on system A, since system A defines macros."
Something finer-grained would be great, but this seems like an absolute
minimum.

7.  I believe it should be easier to affect the operation-chaining.  So,
for example, if one introduces some sub-class of compilation operations
at a system, one might wish to propagate these operations up the
dependency chain.  Perhaps some rethinking of make-sub-operation would
be helpful.

Best,
Robert
-- 
Robert P. Goldman
Senior Scientist
Smart Information Flow Technologies (d/b/a SIFT, LLC)

211 N. First St., Suite 300
Minneapolis, MN 55401

Voice:	(612) 384-3454
Email:    [email protected]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/