[asdf-devel] Make the CL syntax predictable

[Pascal Costanza]

On 29 Mar 2014, at 18:07, Faré <fahree at gmail.com> wrote:

>> : p-cos
> 
>>> no upgrade, no breakage.
>> 
>> If you can’t upgrade ASDF, you may also not be able to upgrade quicklisp. If you can’t upgrade quicklisp, you may also not be able to get updates to existing libraries. At least, it may be harder than necessary (like in the pre-quicklisp, pre-asdf-install days), and you can’t benefit from the efforts that were put into ASDF and quicklisp to the same extent as others anymore. [1]
>> 
> Sorry, you don't get to demand change and rant against change in the
> same paragraph. You don't get to praise the efforts put into ASDF and
> rail against them in the same paragraph. The same legitimate reasons
> that justify desirable change in your libraries also justify desirable
> change in ASDF. The same things that make these changes desirable are
> the things that break systems that relied on non-portable kludges and
> quirks.
> 
> You only get to discuss whether a particular change is desirable.

That is precisely what I’m discussing, nothing else. The paragraph above is an answer to the suggestion that you can choose not to upgrade ASDF if you don’t like its changes. It’s arguing that one may be in a position where you cannot afford not to upgrade. That’s why some controversial suggestions for change may affect some users more than others.

>> If the proposed change to enforce double-float as a default *read-default-float-format* was unambiguously an improvement, there would be no problem. But it’s not an improvement, not by a long shot. [...]
>> 
> There are two dependent changes being discussed:
> (1) guaranteeing a value of *read-default-float-format*
> and other syntax variables when compiling a library.
> (2) having this value be 'double-float.
> 
> It looks like (2) will definitely not happen.
> 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.)

>> *read-default-float-format* lets you choose between different representations for such generic libraries. The scoping rules for dynamic variables in Common Lisp give you two choices: Either you tell a particular library that it chooses a particular representation for its generically chosen representations - you do this by dynamic binding. Or you tell a set of libraries (all that you are loading from now on) that they should all choose the same representation for their generically chosen representations - you do this by side effect.
>> 
> 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?

>> 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 fact that the proposed changes are discussed so actively is a clear sign that people care about these things.
> And the one way to know whether they'll be discussed is to open the
> discussion indeed.

I agree.

>> [1] I already encountered libraries that don’t load with current ASDF versions anymore, although they are defined as ASDF libraries, which is a shame!
>> 
> Sorry, you don't get to complain unless (1) you issue a bug report,
> and (2) the bug isn't fixed by whichever party actually has a bug,
> whether it's the library or ASDF.

I’m not complaining, I’m just mentioning.

Pascal

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.