unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
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


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