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

[Robert Goldman]

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....

Actually, I'm pretty shocked by the extent that source files /already/
share the attributes of systems.  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.  But we make no attempt to do any such
propagation.  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.

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



best,
r