From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 8KktC1uVCWSz/gAASxT56A (envelope-from ) for ; Thu, 09 Mar 2023 09:14:19 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id cGstC1uVCWQgHwAA9RJhRA (envelope-from ) for ; Thu, 09 Mar 2023 09:14:19 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 06D911B24C for ; Thu, 9 Mar 2023 09:14:18 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paBP5-0000oF-6t; Thu, 09 Mar 2023 03:13:35 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paBP3-0000o6-1r for guix-devel@gnu.org; Thu, 09 Mar 2023 03:13:33 -0500 Received: from mail-0201.mail-europe.com ([51.77.79.158]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paBOz-00070n-6k; Thu, 09 Mar 2023 03:13:32 -0500 Date: Thu, 09 Mar 2023 08:13:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail2; t=1678349600; x=1678608800; bh=rqzkRzoEZYzqjX8qt5kDMdvTwlxY485degf5cEOyde4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=lJTDio/YomAknlnAIDWCW6G1zI0j2hNGs7P8WxPHLa3wc5vKJWY+XwFrtMsV0t+Kq mJSVRLQRn1JD5nQrPEhRy1e95mvrMvUUFotvy0vVHqwqCsaKE3JYTn6tci2HPBsWlc fzm5D3MlJwZFFplKk6DPpqHf8S85FQ5YmNGoCCO6l3SgRkogPDrHWihqmVF9acZzmU U4pam6PQcnJaUiNe6qXC4c3p/fnchFXTFy1mrYfjGN0Mk/6acoCuMbdhXDqHsa6SII ul+SZLWBZ0uKEiLxJdV1UkEeFValcguz6l4NAvZnzB4CtV+eEMcS6w7eR6a2Ua141C IzGRMWnNOFN3A== To: Bruno Victal From: Attila Lendvai Cc: guix-devel , Felix Lechner , Liliana Marie Prikler , Maxim Cournoyer , =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Brainstorming ideas for define-configuration Message-ID: In-Reply-To: References: Feedback-ID: 28384833:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=51.77.79.158; envelope-from=attila@lendvai.name; helo=mail-0201.mail-europe.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678349659; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=rqzkRzoEZYzqjX8qt5kDMdvTwlxY485degf5cEOyde4=; b=jhHlpTrU8Ye5bK86UmzszDv5Xwu441yvegURdNXqw6qTjifaUEc8G6t0vWEKf2a6A/5fxK RcE98ZCUr2AElJUEULlvTdLnnv4xAaVLmNwiqD24z4MubfhjjS9lB/V2J2zy42RBeWW8nI YD6EKsLHyRfxKwkqSSM1QXGCqS950lFSy7aZM0RwkTWkp0nrJkUlAP9qRyXwuIZ5cCAm2k MTuy605Bx2iEpbdwIJJGE5jnYplGPxSUQquN0YEMNZp/+O2BU3FP9iRqwrGb8Y4e6bTvG6 rSS83kLDYiCMBSmTDpHo0Js28+w5IFYS8TLJyCWoXLpS7v+T6eMUc3MlK8/c+A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lendvai.name header.s=protonmail2 header.b="lJTDio/Y"; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678349659; a=rsa-sha256; cv=none; b=d8Q72oN9KJz3x6JjEKx44jah9jkLBMLX324Jl1zvKMjv2BQdAoXgAjXqQPvhFui8D7URXE dfuFJA1IeA0EGC663bEvZvgPx88LE6LhJGe1pd1oTk5CAou+VLcqQhVm3R03JeINuWpQE9 F4LCxnVlQqN+9WZpgTWXWPQC7dv6Q13op9iY/rnLm2TacFLsRO8gzDBx0xsoTOgGvnXFwk 7DH2A/FIFnGGQqTqjETokVEF8hn/fJnkkzec5I2ax97u5oaJb9OFgtpSftL97QqJJNhNrQ V6tTT436OWlvFgfn34jy4LsAKhJhkYWq9If5BYlFkhFjQlYZuvtvsBlNLVoPXw== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lendvai.name header.s=protonmail2 header.b="lJTDio/Y"; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none X-Migadu-Spam-Score: -0.70 X-Spam-Score: -0.70 X-Migadu-Queue-Id: 06D911B24C X-Migadu-Scanner: scn1.migadu.com X-TUID: HkgvzsT6oQu3 > Record Validator > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 > 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 th= is at the very beginning: (set! config (apply-config-defaults config)) maybe this validator logic could be implemented so that the validator may r= eturn a new config instance, and all entry points to the service's code wou= ld be called with that new instance? > Coalesced documentation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 "", afte= r wasting some time on a failed compilation. especially in a phase where th= e code is still in a prototype phase. > Kind of a late realization, but couldn't many of the items above be satis= fied > by improvements to define-record-type* instead? > (define-record-type* paired with a documentation literal is nearly equiva= lent to define-configuration, > sans the serialization scaffolding) even if so, i'd still maintain a thin layer of abstraction for communicatin= g the intention, and also for possible future extensions. --=20 =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- =E2=80=9CHe who flatters a man is his enemy. He who tells him of his faults= is his maker.=E2=80=9D =09=E2=80=94 Confucius (551=E2=80=93479 BC)