On Sun, Mar 16, 2014 at 11:25 AM, Robert P. Goldman rpgoldman@sift.info wrote:
Whichever makes sense for the given system, and that's the feature: the user doesn't have to know which newfangled operation the system is using, that will do the Right Thing™. Once again, the person who knows the Right Thing™ is the system author, so they get to specify the operation via :build-operation. The user calls (asdf:build "foo") or (asdf:make "foo"), and the Right Thing™ happens. The user justs want to use the system and gets it to do its thing.
I still don't follow this claim. Consider my example again. I'm the user. I don't know whether (MAKE "FOO-SYSTEM") is going to load FOO-SYSTEM into my current lisp image or dump a standalone executable.
So I type (MAKE "FOO-SYSTEM"). In what sense do I know how to get it to do its thing now? I don't know whether I should be exiting lisp and returning to the shell to invoke an executable, or whether I should be calling some API functions.
I apologize if I seem dim, but I don't see how this hypothetical MAKE function actually creates more simplicity than confusion.
The thing is, make does not *replace* load-system, but complements it. If the user knows he wants to load things only, and not do anything else that might interfere with his interaction, he keeps using load-system. If he wants to do the "default thing for the system", he uses make. Often, the system can instruct him to use (asdf:make :foo) instead of (asdf:oos 'asdf:build-op :foo), or worse (asdf:oos "some-weird:operation" "foo")
I consider it a bug that some Lisps always quit on dumping an executable, rather than offering the option to fork before dump — but a bug too onerous to fix at present. Problem is, it's not always safe to fork, when there are multiple threads. But if the subset of Lisps that quit after dump is small enough and intersects with a subset of Lisps where we know how to fork safely (or cerror before dump). dump should take a quit key arg, possibly so might image-op and program-op, and a cerror should happen if the program needs to quit but wasn't requested and/or was explicitly asked not to.
create-image instead of dump-image, doesn't quit: ecl, mkcl dump-image doesn't quit: clisp, allegro, lispworks, dump-image quits: sbcl, ccl, cmucl error while dumping: gcl neither dump-image nor dump-image: abcl (but has abcl-jar), xcl. Not tested: corman, scl, rmcl, genera.
Fork could be made to work with SBCL and CMUCL. Actually, I already have code in POIU for SBCL to fork, and CMUCL is similar, SCL probably the same. The only tricky one, then, is CCL, that cannot safely fork unless you started it with my "single-threaded-ccl" hotpatch.
In any case, this looks like a separate issue.
The use case I *do* understand is one where, for example, the system provider knows that to make the system usable I should *both* do LOAD-SYSTEM *and* (OOS 'DOC-OP <SYSTEM>) because the system provider knows that the system has a manual, which requires formatting; something the user cannot be expected to know.
I'm also thinking also in terms of secondary systems: if you (MAKE :FOO), it might load it with LOAD-OP but if you (MAKE :FOO/TEST) it might test it with TEST-OP and if you (MAKE :FOO/DOC) if might produce use MY-DOC:DOC-OP, which you can't even refer to right now until after you (LOAD-SYSTEM :MY-DOC). Then, even if, say, there is no convention as to which documentation generating system is best, there might be a convention that FOO/DOC is the documentation for FOO.
As a demonstration, ASDF could replace the asdf/Makefile for all but bootstrap purposes: the Makefile could delegate all requests to ASDF except for the initial building of asdf.lisp itself (in case there's no asdf yet to build it). Not to pollute asdf.asd and everything that loads it (i.e., everything), this infrastructure would be in a separate make-asdf.asd.
I'm not going to kick and scream too much about this since, as I said, I don't think it's actively harmful. But I am not ready to make the end-to-end modifications to the ASDF manual required to substitute MAKE for LOAD-SYSTEM, and I'm unconvinced that this is the Right Thing.
Not substitute. Complement. Maybe new default. But not substitute.
I will therefore leave this on the BUILD-OP topic branch until after the next release.
I think that with or without any "substitution", the code would be better before the release, but you're the master.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org We reject: kings, presidents and voting. We believe in: rough consensus and running code. — David Clark for the IETF