Should marking a system preloaded drop its build information?

[Faré]

On Thu, Sep 15, 2016 at 2:41 AM, Daniel Kochmański <daniel at turtleware.eu> wrote:
> Additional adventage is a more uniform handling of the code (for
> instance in `find-system') and could pave a way for `monotonic-system'
> (from lack of better name atm) – system which only upgrades to the
> higher versions like ASDF does right now.
>
That would require a way of detecting the version before you load the
system, for which ASDF has an ad hoc protocol that doesn't fit the
normal system definition protocol. ASDF is a bit special because it
has to be able to upgrade itself while it's running. Other systems
don't usually have this constraint -- they can ask ASDF to upgrade
them.

> Rationale for registering a new system is as follows: preloaded-systems
> and immutable-systems are separate kind of system treated differently in
> the code and have a separate class, because of their very nature.
>
I don't buy that. Immutable systems could be made thus by adding a
slot immutable-p to all systems. The reason we're using a table
instead is because we want fast access to the list of only those
systems that are immutable without groveling a large list of all the
defined systems, that most usually aren't. At which point we don't
need the slot.

> [To preserve the build information] an instance could store the original system in
> a slot, which gets registered during the call to
> `deregister-immutable-system'.
>
If you preserve the build information, why change the system object at all?

You seem all set on defining new classes for preloaded and immutable systems,
but don't explain why it's useful, just offer workaround for all the
detrimental effects
of the design.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
I'd rather write programs that write programs than write programs — Dick Sites