Plans for ASDF 3.3

[Faré]

On Thu, Apr 27, 2017 at 10:35 AM, Robert Goldman <rpgoldman at sift.net> wrote:
> On 4/26/17 Apr 26 -7:46 PM, Faré wrote:
>> On Wed, Apr 26, 2017 at 7:17 PM, Robert Goldman <rpgoldman at sift.net> wrote:
>>> On 4/26/17 Apr 26 -6:33 AM, Faré wrote:
>>>> What more, it was a hurdle on
>>>> the road to making a future ASDF a robust system with deterministic
>>>> builds.
>>> I wanted to ask about this.  Right now ASDF systems are (in general)
>>> partially ordered.  Is it your plan to make sure there are no
>>> implementation or state dependencies in how these partial orders are
>>> linearized, in order to make it deterministic?
>>>
>> Well, a really deterministic variant of ASDF, if it ever happens,
>> would be based on cross-compilation in separate processes, similar to
>> how Lisp builds currently happen with Bazel. Handling self-extension
>> and phase separation properly in this context might be "interesting".
>>
>
> OK, but I think that should be a different thing -- perhaps POIU version
> 2, rather than an ASDF version.
>
> It's ok to adapt ASDF to support programming in the large, but not, I
> think, too much at the expense of conventional, smaller projects.
>
> At some point, probably the tool support for very large and smaller,
> more conventional systems, should diverge.
>
I agree that one essential constraint of ASDF is that it should keep
working in-image in the small and not depend on external processes or
additional libraries. Any "deterministic build" extension should
remain an extension indeed (though one you'd load early).

However, if this extension is to remain compatible with ASDF and its
.asd file, modifications and cleanups may have to be done to ASDF
itself so it behaves well: even keeping that hypothetical
deterministic build separate, I expect non-trivial changes to the ASDF
API to enable, e.g. cross-compilation (i.e. a perform-form to replace
perform, with perform as the fallback). I hope a backward-compatible
trick can be found for a smooth transition.

But you do well to mention POIU: adapting ASDF so POIU would be a nice
extension was decisive in simplifying the internals of ASDF 2 and ASDF
3. Indeed quite a few incompatible modifications of the internals were
informed by this it, from the fine structure of the
component-depends-on, operate and perform-with-restart methods to the
internal representation of timestamps to the structure of traversals
(notably replacing do-first with needed-in-image-p) and the upward-
and downward- (and more) operation classes, etc.

Thus, I expect the design of the base ASDF to keep being influenced by
such tools.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. — John F. Woods