Thoughts on CL-scripting

Robert Goldman rpgoldman at sift.net
Mon Feb 29 20:21:14 UTC 2016


On 2/29/16 Feb 29 -1:37 PM, Attila Lendvai wrote:
>> 3- It fails badly when asdf itself is so broken that it can't load
>> asdf-tools. I only very recently (January 2016) modified the lisp
>> scripting infrastructure to build an executable ./build/asdf-tools the
>> first time they are called, hopefully with a stable working asdf.
> 
> isn't this a standard bootstrapping issue?
> 
> and the usual way to resolve that is to use git to check out the
> latest stable version into a tmp dir, build the tool, and then use the
> freshly built tool to test the bleeding edge.
> 
> for reference gambit scheme has a sophisticated method set up for
> adding new features that are then used in the compiler implementation
> in version n+1.
> 

This isn't really a standard bootstrapping issue, and I think it's
better to break the vicious cycle by simply booting the scripting engine
out into a separate repository.

Here's the (I believe simple) approach:

1. Set up a repository that provides a *general* CL-scripting capability.

2. Build that capability using only stable tools.

3. Provide in the ASDF repository code that simply uses the CL-scripting
capability.  I.e., just provide CL scripts there, and not the scripting
engine.

At this point we would have broken the vicious cycle, and the CL
scripting engine would play a role akin to perl, make, etc., in the ASDF
development process.

Instead, right now we have things like ASDF requiring to test that it
successfully be able to build a tool suite using a new ASDF capability.

Note that this is what I'm suggesting *in the abstract*.  Right now, the
CL scripting framework is not, IMO, ready for prime time.  I'm not
willing to wrestle with undocumented, untested code as a precondition
for simply fixing ASDF bugs.

I'm not saying that it's bad that CL scripting is at a primitive state
now -- that's a state all software has to go through.  All I'm saying is
that CL scripting has a lot of promise, but it's not the kind of tested
tool I require for ASDF development, and it's not going to get there
(IMO) for some years yet.

So I am backing slowly away from it....





More information about the asdf-devel mailing list