From: antlers <antlers@illucid.net>
To: "Liliana Marie Prikler" <liliana.prikler@gmail.com>, guix-devel@gnu.org
Subject: Re: A friendlier API for operating-system declarations
Date: Sun, 25 Feb 2024 10:49:19 -0800 [thread overview]
Message-ID: <1ab54235-ecfe-43df-afce-e45ca6aba1c1@app.fastmail.com> (raw)
In-Reply-To: <748f644460181e086c694333a1faa2c730452a99.camel@gmail.com>
> 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.
next prev parent reply other threads:[~2024-02-25 18:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 22:25 A friendlier API for operating-system declarations antlers
[not found] ` <87plwrj3w9.fsf@rdklein.fr>
2024-02-20 3:42 ` antlers
2024-02-25 9:26 ` Liliana Marie Prikler
2024-02-25 18:49 ` antlers [this message]
2024-02-25 20:47 ` antlers
2024-02-25 20:50 ` Liliana Marie Prikler
2024-02-25 21:27 ` antlers
2024-02-26 19:58 ` Liliana Marie Prikler
2024-03-01 16:44 ` Hartmut Goebel
-- strict thread matches above, loose matches on Subject: below --
2023-05-19 3:31 antlers
2023-03-23 8:06 Edouard Klein
2023-03-23 18:48 ` Josselin Poiret
2023-03-23 20:23 ` Edouard Klein
2023-03-23 21:05 ` Liliana Marie Prikler
2023-04-13 9:42 ` Ludovic Courtès
2023-05-18 14:37 ` Edouard Klein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ab54235-ecfe-43df-afce-e45ca6aba1c1@app.fastmail.com \
--to=antlers@illucid.net \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).