From: Attila Lendvai <attila@lendvai.name>
To: Bruno Victal <mirai@makinata.eu>
Cc: guix-devel <guix-devel@gnu.org>,
"Felix Lechner" <felix.lechner@lease-up.com>,
"Liliana Marie Prikler" <liliana.prikler@gmail.com>,
"Maxim Cournoyer" <maxim.cournoyer@gmail.com>,
"Ludovic Courtès" <ludo@gnu.org>
Subject: Re: Brainstorming ideas for define-configuration
Date: Thu, 09 Mar 2023 08:13:10 +0000 [thread overview]
Message-ID: <p2BwiyERUz7JLgGtk4AJU1drfqypMDbLBrEtdo5RTrWFDOqlL7pl3F8iMc_gYK6aoF0mppPoJbEVhEgc-ocfJKQIyaTxcLjDcIhLsRlv0Aw=@lendvai.name> (raw)
In-Reply-To: <ec01cb0c-e7f7-6824-1a4a-c2a45c789808@makinata.eu>
> Record Validator
> ===============================================================================
>
> There is also a need to validate records. Matching fields alone do
> not actually ensure that the configuration is coherent and
> usable. For example, some fields may be mutually incompatible with
> others.
>
> We could provide procedures that validate each record type within
> define-configuration itself instead of validating the value at
> runtime (i.e. within the body of the service-type).
in my service i have a non-trivial logic regarding defaults (e.g. there are cross-field dependencies while setting some defaults).
this means that all the entry points to my service code have a line like this at the very beginning:
(set! config (apply-config-defaults config))
maybe this validator logic could be implemented so that the validator may return a new config instance, and all entry points to the service's code would be called with that new instance?
> Coalesced documentation
> ================================================================
it's a tangential here, but i think demanding a documentation for fields is just wrong. all it does is annoy the programmer who puts an empty "", after wasting some time on a failed compilation. especially in a phase where the code is still in a prototype phase.
> Kind of a late realization, but couldn't many of the items above be satisfied
> by improvements to define-record-type* instead?
> (define-record-type* paired with a documentation literal is nearly equivalent to define-configuration,
> sans the serialization scaffolding)
even if so, i'd still maintain a thin layer of abstraction for communicating the intention, and also for possible future extensions.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“He who flatters a man is his enemy. He who tells him of his faults is his maker.”
— Confucius (551–479 BC)
next prev parent reply other threads:[~2023-03-09 8:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 2:28 Brainstorming ideas for define-configuration Bruno Victal
2023-03-09 8:13 ` Attila Lendvai [this message]
2023-03-09 21:05 ` Josselin Poiret
2023-03-09 14:40 ` Joshua Branson
2023-03-09 20:23 ` Liliana Marie Prikler
2023-03-10 14:10 ` Maxim Cournoyer
2023-03-10 20:15 ` jbranso
2023-03-10 22:37 ` Liliana Marie Prikler
2023-03-15 16:27 ` Ludovic Courtès
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='p2BwiyERUz7JLgGtk4AJU1drfqypMDbLBrEtdo5RTrWFDOqlL7pl3F8iMc_gYK6aoF0mppPoJbEVhEgc-ocfJKQIyaTxcLjDcIhLsRlv0Aw=@lendvai.name' \
--to=attila@lendvai.name \
--cc=felix.lechner@lease-up.com \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@gmail.com \
--cc=ludo@gnu.org \
--cc=maxim.cournoyer@gmail.com \
--cc=mirai@makinata.eu \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.