[asdf-devel] What do I win?

[Robert Goldman]

On 10/15/10 Oct 15 -2:00 PM, Pascal J. Bourguignon wrote:
> Robert Goldman <rpgoldman at sift.info>
> writes:
> 
>> On 10/15/10 Oct 15 -12:15 PM, Nikodemus Siivola wrote:
>>> On 15 October 2010 20:03, Robert Goldman <rpgoldman at sift.info> wrote:
>>>
>>>> Right.  But, honestly, I find
>>>>
>>>> (:module "ports"
>>>>   :components
>>>>        (
>>>>         #+sbcl
>>>>         (:file "sbcl")
>>>>         #+ccl
>>>>         (:file "ccl"))
>>>>  ...)
>>>>
>>>> a lot easier to read...
>>>
>>> Sure -- but it makes system-introspection limited to the
>>> implementation you are currently using.
>>
>> I get it, but the value of such introspection seems, at the moment,
>> primarily conjectural, but the bewilderment of :if-component-dep-fails
>> is certain.  
> 
> Not really.  
> 
> For example, documentation generators use ASD files to as documentation
> root.  It would be better if they could gather and document the various
> implementation specific parts without playing game with the lisp reader.

Agreed.  But the number of systems that have such documentation
generators are EXTREMELY limited.

We have a bunch of systems that just use variations of Edi's hack that
simply use the package system, and ignore the ASDF-ness entirely.

Once upon a time I tried to use one of the ASDF-based doc generators (I
believe it was Gary's TINAA) and found that the generator had to
replicate so much of ASDF in it (and a fair amount of the Lisp reader,
too!) that it was too brittle to be practical.

The problem is that ASDF is, even when introspective, all about FILES.
But Lisp documentation systems typically are centered around SYMBOLS,
and there's no easy way to go from ASDF system definitions to SYMBOLS.
It's a heck of a lot easier to go from *PACKAGES* to SYMBOLS....
> 
> So a nice syntax/semantics like that proposed by Daniel would be
> beneficial, and could perhaps slighly promote the development of an
> ecology of static analysis tools.

Despite the above, I agree with you about this --- IF it's possible to
have readable system definitions AND introspection, then that's
obviously The Right Thing.

But given the status quo, where you can have readable system definitions
OR (exclusively) introspection, I'll take readability.

Best,
r