On Thu, Apr 27, 2017 at 10:35 AM, Robert Goldman <rpgoldman@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@sift.net> 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)
On 4/26/17 Apr 26 -6:33 AM, Faré wrote: 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