Thoughts on CL-scripting

[Robert Goldman]

Originally, I was very concerned to minimize the overhead of
dependencies for building and testing ASDF, and I still think this is
important.

But I now conclude that trying to pull in the cl-scripting
infrastructure was wrong, because it had the side effect of making the
system used for testing be a dependency of the system under test,
introducing unhealthy circularities.

Going forward, if you want to experiment further along these lines, I'd
suggest an entirely separate project -- with its own test suite! -- that
would build an executable capable of executing CL scripts.  That
executable would have to NOT require bleeding-edge ASDF capabilities,
only simple core capabilities.  It should be built with the ASDF that's
delivered with implementations, not with bleeding-edge ASDF.

That executable could be built, saved, tested, and installed, and then
could be used as the engine for ASDF building, testing, etc., if one
liked.  It could be a required build tool, the way today "make" is a
required build tool.

To be honest, I think such an engine should first be tested with much
less demanding problems than building and testing ASDF.  Simple
scripting tasks, say within the ambit of the /Perl Cookbook/, would be a
reasonable starting point.

Even doing this, I think there's only a 50-50 chance the approach will
work out.  CL's numerous incapabilities where dealing with the host OS
and filesystem will still stand in the way.  Committing to a single
implementation -- probably CCL or SBCL -- might solve this problem.  A
less cumbersome means of line-by-line processing of streams should be
developed, and some means of using regexp literals should be added.
Variable interpolation into strings should be provided.

Just some thoughts....

Best,
r