In article <AANLkTimQqsEthHPUgC7cda1Wz_3Q4UuXZ5NEQpKDB2Ds@mail.gmail.com>, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com> wrote:
On Thu, Aug 19, 2010 at 10:13 AM, Tobias C Rittweiler <tcr@freebits.de>wrote:
Now I'm wondering how good that solution is.
Bad. I already spoke about why I am against reader conditionalization in ASDF files. Dependencies should only be either features (strictly CL implementation dependent not the ones introduced by libraries) or modules (thus recognized by ASDF), which may themselves be optional or compulsory and ASDF should provide a good syntax for both.
The parts you left out did not talk about reader conditionalization in ASD(F) files. So I'm confused by what you mean exactly. The library author somehow has to arrange for condition compilation. ASDF could make per-file conditionalization easier, but sometimes you want per-toplevel-form conditionalization. That's what #+,#- provide which work on *FEATURES*. I don't see a way around that other than ASDF providing an analogous reader macro around FIND-SYSTEM.
What is if the library was compiled with a core that happened to include named-readtables? Trying to load that fasl with another core file would probably result in an obscure error. Now, it's a shoot-yourself-in-the-foot kind of thing to do, but I'd think it's something that can happen quite easily. Does ASDF somehow guard against this case?
This is one of the reasons why reader conditionalization is bad: the dependency is stored outside ASDF, in *features*, which is not good. If one sticks to ASDF, it would recognize the named-readtables modules to be present in the core and thus it would work, or it would not find it and then it would load it.
Indeed that was my point. Try to load it, if that does not succeed, it should barf an error. -T.