[asdf-devel] Make the CL syntax predictable

[Attila Lendvai]

>> and if this state can be set in a way that it leaks out and influences
>> builds later in time, then it's an ugly bug feasting on programmer
>> nerves and time.
>>
>
> This would be true only if "a software" was equivalent to "an ASDF
> system."  That is not the case.  I have seen many applications that are
> made up of a large number of ASDF systems, because ASDF does not
> necessarily provide nice structures for large applications.  In such


we also have libs with 10+ asdf systems.


> application builds, you WANT state to bleed from one ASDF system to
> another, because these ASDF systems are not freestanding entities.


one can write a trivial loader file that calls ASDF with some extra
keyword parameters to load such systems.


> Complaining that state leaks in and out of these systems is like
> complaining that state leaks into a closure.  It's intended to leak, and
> that is not a bug.


the vast majority of the asdf systems don't want leakage, and defaults
should be covering the majority use-case (if/when it's possible
without setting up landmines).

reproducible builds are a valuable feature.

if i wanted to cater for the use-case you described then i'd still
make full isolation the default with features to let systems
explicitly turn off specific isolations, or just simply let them on
their own to subclass and customize ASDF the way we currently have to
subclass and customize asdf to avoid the leakage from the hu.dwim.*
universe (we use e.g. readtable customizations).

and whoever is not ready to invest time in following the changes,
should simply not upgrade, and then it's a non-issue. but this starts
to feel like preaching and i don't really have that much stake in this
anymore because we have already invested in covering our bases... so,
these are just some 0.02...

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The three most harmful addictions are heroin, carbohydrates, and a
monthly salary.”
	— Nassim Taleb (1960–)