[asdf-devel] Feature-conditional components

Daniel Herring dherring at tentpost.com
Sun Oct 24 18:01:14 UTC 2010

On Sun, 24 Oct 2010, Robert Goldman wrote:

> On 10/22/10 Oct 22 -11:56 PM, Daniel Herring wrote:
>> On Fri, 22 Oct 2010, Faré wrote:
>>> 2- is depending on a suppressed component a bug, a nop, or something
>>> that forces the component to be un-suppressed?
>> If X depends on Y, and Y has been disabled, then X cannot load properly.
>> Was Y a requirement for X, or just something that should load earlier?
>> If the former, then X should not be allowed to load.  If the latter,
>> then there's no issue.
>> If X is not allowed to load, under what circumstances should this cause
>> the operation to fail?
>> Rather than ponder these ambiguities, maybe it would be better to let
>> the user insert errors where they belong, possibly using IF clauses?
>> Then ASDF could adopt the simple rule of proceeding unless told otherwise.
> I'm reluctant to see us go down this path.
> The primary advantage of having feature dependencies, over the #+
> mechanism that CL already offers us, is that feature dependencies are
> declarative and enable introspection.

And error declarations do not prevent that.

> If we let people write programs in feature dependencies, these
> advantages will go away.
> Without those advantages, we might as well not complicate ASDF with
> feature dependencies; we can just let system definers continue to use
> reader conditionals....
> So I'd suggest we define simple policies along the lines that Faré suggests.

That's find if people can agree on simple, flexible semantics.  I made 
this suggestion because it seemed simple and flexible.  C++ has taught me 
a dislike of coupling separate concepts together (e.g. struct vs class vs 

- Daniel

More information about the asdf-devel mailing list