ASDF components are brittle for backwards compatibility

Stelian Ionescu sionescu at cddr.org
Thu Apr 29 16:42:39 UTC 2021


> ASDF checks to make sure all of the initargs are defined when parsing a `defsystem`. This is good for catching errors, but is terrible for extensibility. This means that any attempt to add additional metadata will be backwards incompatible.

> I can think of two ways to fix this:

>  1. Add a "garbage can" slot to `component` that will be filled with a property list, and allow programmers to do whatever they want here. This doesn't seem great to me.

>  2. Add a new `defsystem` parsing error class that is `unknown-component-property`, raise it when an unknown property is encountered and allow the user to continue, discarding the initarg and accompanying value.

> The second alternative is what I favor. It isn't great, because it will only maintain extensibility going forward, but I think it's the best we can do.


How can ASDF or a developer determine that the unknown property doesn't change the semantics of the DEFSYSTEM, and therefore discarding it would have an effect that's contrary to the author's intention ?
ASDF has no syntactic distinction between properties that affect the compilation process and mere annotations like author, licence, etc...


> I suppose that we could also add an initarg to tell ASDF to continue such errors silently.

> I'd be inclined to suggest that this take an ASDF version expression as value, so that the error is quietly ignored only by ASDF versions below that. This means that the property will start to be checked when it has become authoritative.
> Note that for one's own `system` and `component` subclasses, the set of initargs can be extended without any monkeying around.



This is a recipe for maintenance nightmares. Let's not go there.

--
Stelian Ionescu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20210429/1f14d145/attachment.html>


More information about the asdf-devel mailing list