Re: A friendlier API for operating-system declarations

[antlers]

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