[asdf-devel] Feature-conditional components

[Daniel Herring]

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 
namespace).

- Daniel