> That looks like a nice syntax indeed. Is the code behind it small > enough to include it in (guix records)?
Small enough? Yes (<100 LOC, inc. a handful of comments and tests). Suitable? No, I introduced it as "moderately-cursed" for a reason >u< But I appreciate the sentiment c: 1.) It leaks `(guix records)`'s thunked/delayed field abstraction to the end-user, which will confuse and regularly bite absolutely anyone who tries to use it. 2.) Ideally we'd check that modified fields exist at compile-time. This could require users to provide the record-type, which is not always public, but could also be optional. 3) The `cut`-like transformation is recursive and, while it has well-defined and tested behavior, the semantics are non-standard. I don't believe that the syntax achieves its goals without this mechanism, but there are remaining sub-concerns to address before I'd consider it ready to formalize and document. 4) The syntax expands modifications of multiple fields into recursive expansions (ie: calls to the record constructor) when it would be more efficient (especially for thunked/delayed fields) to accumulate transformations by target field and `compose' them over a single call to the record constructor. This hasn't been an issue in practice, but would be the "right thing to do". #3 and #4 are a light refactoring and feedback-round away (#3 could be controversial), but #1 and #2 require deeper understanding and (especially for #1) modification of `(guix records)' than I'm comfortable with at the moment. If I do raise the possibility of up-streaming it would be with these issues addressed, and would still have substantial cause to warrant discretionary discussion then. Really a scratching-my-own-itch solution atm.
