From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: antlers <antlers@illucid.net>, guix-devel@gnu.org
Subject: Re: A friendlier API for operating-system declarations
Date: Sun, 25 Feb 2024 21:50:51 +0100 [thread overview]
Message-ID: <b0f6da7d2c3fc9c88f11151f6ebf75051fcf3312.camel@gmail.com> (raw)
In-Reply-To: <1ab54235-ecfe-43df-afce-e45ca6aba1c1@app.fastmail.com>
Am Sonntag, dem 25.02.2024 um 10:49 -0800 schrieb antlers:
>
> 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.
You can get the record type of a record at run-time, so at least you
can synthesize a check that gives you a helpful message if that's what
you're gunning for.
> 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.
Perhaps we can make it like modify-services where we take a value
updater instead of evaluating the forms directly? This would fix both
#3 and #1 (since we'd unwrap the thunked/delayed field silently).
That would also make it so that we can use a single set of arrows (=>)
for both.
> 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".
That's a minor detail, but it might be a syntax-rules → syntax-case
change.
> 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.
Of course it'd go through the proper review channels first, but from
personal experience talk over at guix-devel is less likely to cause the
change you want over submitting an actual patch :)
Cheers
next prev parent reply other threads:[~2024-02-25 20:51 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
2024-02-25 20:47 ` antlers
2024-02-25 20:50 ` Liliana Marie Prikler [this message]
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=b0f6da7d2c3fc9c88f11151f6ebf75051fcf3312.camel@gmail.com \
--to=liliana.prikler@gmail.com \
--cc=antlers@illucid.net \
--cc=guix-devel@gnu.org \
/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).