On Fri, Aug 20, 2010 at 1:07 PM, Tobias C Rittweiler <span dir="ltr"><<a href="mailto:tcr@freebits.de">tcr@freebits.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

The parts you left out did not talk about reader conditionalization<br>
in ASD(F) files. So I'm confused by what you mean exactly.<br></blockquote><div><br>Sorry, I understood the reader macros were intended to appear in the ASDF itself. I obviously misread your email, but I needed a third reading to grasp it all -- please tell me whether the following description is right :-)<br>

<br>Goal:<br>Library B has some facilities that make sense when library A is present. The goal is to make these facilities compiled and loaded whenever possible.<br><br>Solutions offered:<br><br>1) Let the library B :weakly-depends-on A and use the fact that library A introduces a new feature. The code in library B is then populated with #+/#- depending on that feature.<br>

<br>2) One of the components in the system definition includes all the code that depends on A and is loaded only when that :feature is active<br><br>3) One of the components in the system definition isolates all dependency on A and this component :weakly-depends-on <br>

<br>4) Make two separate system definitions, one with and one without code for A<br><br>I believe 1 and 2 have problems because as you say the feature might be present in the core. #3 is better because the code that depends on A is only loaded when ASDF knows that A is present and loadable -- no dependency on non-standard features. Method #3, if working (which Fare seems not to be sure about) is also the substitute for reader macros in ASDF files.<br clear="all">

</div></div><br>Juanjo<br><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>