[asdf-devel] ANU, or changes which should be backported to ASDF 1.0 [ Re: Enforcing pure *.asd files (1)

james anderson james.anderson at setf.de
Wed Mar 24 01:01:16 UTC 2010


On 2010-03-24, at 00:08 , Robert Goldman wrote:

> On 3/23/10 Mar 23 -8:35 AM, james anderson wrote:
>> good morning;
>>
>> On 2010-03-18, at 21:41 , Juan Jose Garcia-Ripoll wrote:
>>
>
>>
>> Contributing to this problem is that the system and component  
>> forms are
>> not symmetrical. The intended syntax is[2], but the implementation  
>> is not:
>>
>> ? (defclass specialized-system (asdf:system) ())
>> #<STANDARD-CLASS SPECIALIZED-SYSTEM>
>> ? (defclass specialized-source-file (asdf:cl-source-file) ())
>> #<STANDARD-CLASS SPECIALIZED-SOURCE-FILE>
>> ? (eval '(asdf:defsystem :a-system :class specialized- 
>> system :components
>> ((:file "a-file"))))
>> #<SPECIALIZED-SYSTEM "a-system" #xEF6724E>
>> ? (eval '(asdf:defsystem :a-system :class specialized- 
>> system :components
>> ((:file "a-file" :class specialized-source-file))))
>>> Error: :CLASS is an invalid initarg to REINITIALIZE-INSTANCE for
>> #<STANDARD-CLASS ASDF:CL-SOURCE-FILE>.
>>>        Valid initargs: #(:CONTINGENT-ON :LONG- 
>>> DESCRIPTION :DESCRIPTION
>> :NAME :VERSION :IN-ORDER-TO :DO-FIRST :PARENT :PATHNAME :PROPERTIES).
>>> While executing: CCL::CHECK-INITARGS
>>> Type Command-. to abort.
>> See the Restarts… menu item for further choices.
>> 1 >
>>
>> This should be corrected, in order that - even in the absence of an
>> intended extension, asdf can interpret the standard information in a
>> system definition.
>
> Please launchpad this bug, with a list of the set of initargs that  
> need
> to be supported.  Maybe this can be fixed.
>
> I am willing to believe that the initargs to system should be  
> supported
> on components to the maximum extent possible.  But I don't see any
> reason, a priori, that components and systems should be treated
> symmetrically.  Why should we believe that, of necessity, every  
> form of
> source file should be modeled by a data structure that shares every
> attribute of a system?  To take an absurd case, we don't put file
> extensions on systems....

please reconsider whether, that one does not now really means that  
the particular feature should not be treated symmetrically.

i can't answer the question, as i've not considered the implications,  
but, given how obviously ill-considered the :class treatment is, i  
would first presume symmetry and exclude upon deliberation.
? what happens of one loads a system definition from a file which is  
not marked type "asd"?

>
> Actually, I'm pretty shocked by the extent that source files /already/
> share the attributes of systems.

one should more often boggle ones mind.

>   For example, source files, as
> components, have :version attributes.  But surely if one wanted to  
> have
> versions on source-files, there should be some inheritance  
> relationship
> between the :version one specifies on a parent system and the version
> specified for its components.

given how little i comprehend the version's practical effects, i  
would not neither deny nor confirm that.

>   But we make no attempt to do any such
> propagation.

i would, however, not admit that such a practice, in itself,  
indicates what should or should not be done.

>   Nor, since the :version is a property that lives in the
> system definition, and since the :version property of a component  
> is not
> readily checkable across system boundaries, does associating versions
> with components make any particular sense.

is there some inherent reason, by which version-ness does not  
propagate upwards? for example from the files which apply given  
implementation conditionalization to the system from which they are  
built? as noted, while unaware of how people actually use it, i would  
not presume asymmetry.

>
> The :class case, I'll grant you, /does/ make sense, but I'm not
> confident we should extrapolate too far from that.

if one would go through each initialization argument and consider the  
implications of each, i would be more inclined to believe.






More information about the asdf-devel mailing list