Re: Issues noticed while extending asdf

[email protected] writes:

> 1. A new package created each time an asdf system definition is loaded.

To avoid polluting CL-USER or ASDF, yes.  People are allowed to
designate component names with symbols, and some newbie somewhere is
going to get very confused when stuff starts appearing in CL-USER

> These packages are not flushed when the system is redefined or deleted.

This would be nice

> Even if you throw in an in-package in the system definition a new
> package is created. Why is this? If you don't want to use the cl-user

Because afaik there's no nice way prior to loading a file to tell that
it contains an in-package form.

> package, why not create a single asdf-systems package? By the way, a new
> package is created even if we have a definition being reloaded? Why not
> reuse the previously defined package?

I'm not convinced that using the same package for all these systems
would work, but it would certainly be an improvement if the scratch
packages were releted or reused after they're finished with. 

(Deleting or emptying a single ASDF-SCRATCH package before each
operation sounds like a really good way to eventual freaky bug when
multiple threads might be loading a system at the same time)

> 2. If you have a specialized operation class that adds slots, and you
> set values in those slots, then redefining the system does not get rid
> of the slot values. The problem appears to be that asdf always tries to
> reuse existing system objects when redefining a class. There is explicit
> code to unset some of the slot values in parse-component-form. If you
> add a subclass that defines additional slots, there is no interface for
> unsetting those slots at the right time. This whole problem could be
> avoided if new object instances were *always* created when definitions
> were reloaded, and the necessary data were copied over from the old
> definition. Is there any reason this approach has not been used? It
> would also correctly address the issue of handling components that have
> been removed from a redefined system definition.

The reason, such as it is, dates back to the original design of asdf
in which we thought that people were often going to define
EQL-specialised methods on particular components to do specialised
things (we even have a special shorthand syntax for it, although I'm
not sure that it hasn't bitrotted).  So, we try to preserve object
identity for components - this makes a difference when people evaluate
defsystem forms interactively instead of reloading the whole file

> 3. parse-component-form is a poorly commented monolithic function, and
> for no apprent reason. 

It grew.

> Makes it rather hard to read. In general, it
> appears that asdf source does not document even key functions such as
> perform and operate.

Have you looked at the README?

> 4. It appears that perform is only called on files, and not on higher
> level objects such as systems and modules. Why is that? If there is a
> property of the system that I want to define at the system level, then
> I want that property to affect the components within the
> system. Presently, asdf does not seem to be set up to accomodate such
> closure.

We have actually tried this both ways, and my recollection is that
there arguemnts against both approaches (sadly, there seems to be
little argument for either of them).  But I can't actually remember
what the issues are right now, so I'll tackle this another time when
I'm more awake.

> I've had to make some minor changes to asdf to accomodate the
> extensions I'm making, I'll pass everything by the mailing list once I
> have them working. (2) and (4) above are larger issues getting in the
> way of the implementation of my extension. The fix for (2) isn't that
> hard. For (4) you will likely have to rethink the present
> traverse-then-perform approach that asdf uses.

That's actually quite likely to happen anyway: the plan-then-execute
approach is a pain far more often than it's actually any use.


-dan

-- 
"please make sure that the person is your friend before you confirm"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAdzEgHDK5ZnWQiRMRAjXFAJ99bzywM3Yof72xjDCj/fki5c1fQACfVOzy
aQ6V9N+6nhqGhGUhVWcvVQk=
=2KhX
-----END PGP SIGNATURE-----