[asdf-devel] Optional dependencies

[Tobias C Rittweiler]

In article 
<AANLkTimQqsEthHPUgC7cda1Wz_3Q4UuXZ5NEQpKDB2Ds at mail.gmail.com>,
 Juan Jose Garcia-Ripoll 
 <juanjose.garciaripoll at googlemail.com> wrote:

> On Thu, Aug 19, 2010 at 10:13 AM, Tobias C Rittweiler 
> <tcr at 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.