On 29 Mar 2014, at 19:47, Faré <fah...@gmail.com> wrote: >>> (1) guaranteeing a value of *read-default-float-format* >>> and other syntax variables when compiling a library. >>> I still argue that (1) is essential for build determinism, >>> and enabling users to change syntax at the REPL. >> >> Are you also considering the following use case? >> >> - Assume I’m developing a library for a specific Common Lisp implementation. >> Let’s choose LispWorks as an example, although it could be any other. (I’m >> just choosing LispWorks as an example because I happen to use it myself most >> often.) LispWorks comes with its own system definition facility, and with >> its own default values for pre-defined global variables in the CL package >> that may or may not be the same as those of other CL implementations. Since >> I’m also maintaining portable libraries, I prefer to use ASDF even for >> LispWorks-only libraries, so I don’t have to change tools on a regular >> basis. However, I would also like to make sure that LispWorks users can use >> the LispWorks system definition facility for my library as an alternative. >> Will it be possible to use ASDF without it messing with the default values >> for pre-defined global variables, so that I have a guarantee that I get the >> same result no matter whether I use ASDF or some other system definition >> facility? (I’m fine with doing extra work in the system definitions, but I’m >> not sure I’d be fine with adding extra headers to the lisp files.) >> > I admit I have only limited knowledge of LispWorks's defsystem — but > that it made me appreciate Dan Barlow's design better (though not his > implementation). Writing LW defsystem rules to process dependencies > correctly is *possible*, but by no means trivial. I don't know what > guarantees the LW defsystem does or does not provide in terms of > variable bindings — if you know it, it would be great of you to > explain what they are (or just link to a page that does, if there is > one). Indeed, if these assumptions differ from those of ASDF today or > tomorrow, it would be nice to have a simple way to declare around > wrappers that provide the alternative assumptions.
…same for mk-defsystem, same for Allegro’s system definition facility, and so on. Or maybe, alternatively, such things don’t belong in a system definition facility, but should be covered by some other tool? >>> That's not how it works, unless you include a bit for *rdff* in the >>> name of the fasl cache directory — and since the planning is done >>> based on pathnames before the compilation happens, that should still >>> be *rdff* at the beginning of compilation. Otherwise, the build is not >>> deterministic, and two different toplevel programs will poison each >>> other's builds. >> >> …not even if you :force t? >> > If you make :force t the default, you lose incrementality, and fast > startup time for end-user scripts. If you say "things are unsafe by > default", you lose modularity and you make it impossible to distribute > scripts to end users. Either way, if you don't have a deterministic > build *by default*, easy deployment of scripts to end-users is not > possible anymore. I understand your desire for deterministic builds. I don’t understand your desire for deterministic builds being the default. >>>> You also have the option to fork a particular Common Lisp implementation >>> So do you. That's a non-argument that assumes you're the dictator of CL. >> Huh?!? > The common "love it or leave it" slogan is assuming the utterer owns > the domain at stake. Otherwise, why should YOU not be the one to leave > when we disagree what "love it" means? I believe you are reading too much into what I wrote. I prefer the defaults of the CL implementation of my choice not to be overridden by some tool whose primary purpose is something unrelated to those defaults. That’s all. Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
