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
_______________________________________________
asdf-devel mailing list
[email protected]
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Reply via email to