[asdf-devel] Make the CL syntax predictable

[Pascal Costanza]

On 29 Mar 2014, at 19:47, Faré <fahree at 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.