[asdf-devel] ASDF 2.0 and beyond.

[Faré]

Dear all,

I think that Juanjo's and Janderson's propositions are on the right
track, and I'm glad Juanjo is stepping forward as ASDF maintainer. I
just have a few points to make:

* while being the XCVB author and ASDF maintainer, I've become acutely
aware of the distance between a simple idea, a prototype that works in
the common, a robust product that works in all cases, and a robust
documented library that is suitable for developers, and a polished
product that is usable by end-users.

* I don't think it's demeaning to say that the prototypes developed by
Juanjo or James are not polished products yet. I could argue at length
on the details, but my main point in not including them so far is that
I don't think they are ready for primetime, and I am not willing to
either work out their issues or to delay ASDF 2.0 while said issues
get worked out.

* When Juanjo, Janderson, or someone else takes over after 2.0, it
will be time to mainline those ideas, and the new maintainer will have
to do the painful work of resolving each and every bug until the code
is right. Ouch.

* You don't have to wait until after ASDF 2.0 is released to start
branches or alternate repositories. I would encourage the creation of
such branches.

* Be aware that no branch should be merged in until the code is robust
enough, usable by its target audience, and has someone willing to fix
any issues that come up with testing (and, ideally, includes proper
unit tests).


Now, as of the development and testing process,

* I think Juanjo's investigation of ASDF practice is essential in
establishing what "backwards compatibility" is really needed. If we
know exactly which packages are affected by some change, we can make
that change and fix those packages.

* Janderson's automated testing is also a huge step in the right
direction. As with the ASDF internal test suite, the goal would be to
first establish a baseline what backwards-compatible build success is,
and from there be able to detect and fix regressions.


As for future developments:

* I think the design goals that Juanjo put forward are pretty uncontroversial.

* I will happily argue the devil out of the details of the proposed
patches, but not in this conversation thread.

* Having revamped the internals of TRAVERSE for performance reasons
(but without changing its semantics), I can tell: it sucks, and no one
can sanely be relying on its precise behavior. Don't be afraid of
replacing it.

* When I started XCVB, I didn't think that ASDF was salvageable,
either technically or politically. Thank all of you who participate on
this list for proving me wrong.


Regarding XCVB itself:

* XCVB already embodies a lot of the principles outlined by Juanjo in
this thread and on c.l.l, and what it doesn't have yet it certainly
was intended to have eventually.
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/9451a52099ae25b6/aae522d11e35456e

* XCVB notably has declarativeness of the system specification,
support for generated files, lisp images, cross-compilation, a
compile-and-link model, warning control, etc.

* Like ASDF, it is lacking good support for testing, documentation,
foreign language compilation, shared libraries, general rules, etc.,
although allegedly the basic model of XCVB has room for them in a way
that isn't true for ASDF.

* It is also lacking things that ASDF has, like support for more
implementations than SBCL, CCL, CLISP, a good extension mechanism and
its actual application to compiling CFFI, Ironclad, a working
WITH-COMPILATION-UNIT, etc.

* If you manage to salvage ASDF and make it evolve incompatibly
towards more declarativeness, XCVB will happily be fully compatible
with the new, better ASDF. XCVB might then become "just" an alternate,
out-of-image cross-compiling implementation of the ASDF specification.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
In the long run, John Maynard Keynes is dead. — John Perich