From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 6NCNCSmQC2ROYAEASxT56A (envelope-from ) for ; Fri, 10 Mar 2023 21:16:41 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id yLpaCSmQC2S0TQEAauVa8A (envelope-from ) for ; Fri, 10 Mar 2023 21:16:41 +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 D4BE33EEC3 for ; Fri, 10 Mar 2023 21:16:40 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paj9p-0007S9-E8; Fri, 10 Mar 2023 15:16:05 -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 1paj9m-0007Rt-G7 for guix-devel@gnu.org; Fri, 10 Mar 2023 15:16:03 -0500 Received: from mx1.dismail.de ([78.46.223.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paj9j-0001YI-On; Fri, 10 Mar 2023 15:16:01 -0500 Received: from mx1.dismail.de (localhost [127.0.0.1]) by mx1.dismail.de (OpenSMTPD) with ESMTP id e78fe51b; Fri, 10 Mar 2023 21:15:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dismail.de; h= mime-version:date:content-type:content-transfer-encoding:from :message-id:subject:to:cc:in-reply-to:references; s=20190914; bh=gNPU1qVHByHElH/ogESJdi1v/gwfk3KDx+3WdJLBm0M=; b=BCXnu4X0yk6E BEZ00cFUU6DAcMzFxsZMQRbMVkYtDC3afR4Ug1cm4+7eJAMFjqv5WME3xiKz22Nf Z2/ECI2cfOAtqsVya51BrxZcUOFqjg7aPoSiuS+bWi3MlHDnjn4voBDlW8HRUZbC YwztnJhwBKo2Rqd4IsL2SeXHjc8zWz6H6Vh/sWzRufcRzOGaB/TATFZRvzAb321k D1OmRZzU7TOzqoY4SuXMDHYycpmSM6GYo/f70x7jNvohQYCODi+bMuPnELl6za0a 1h2RUvpuQBJY0OKozl+R9U9j2U3p4ninpLDLH11AqU1lof/wrEZ1D1yCJfIChTgn 9GRPPWNAxg== Received: from smtp2.dismail.de ( [10.240.26.12]) by mx1.dismail.de (OpenSMTPD) with ESMTP id c005d3db; Fri, 10 Mar 2023 21:15:53 +0100 (CET) Received: from smtp2.dismail.de (localhost [127.0.0.1]) by smtp2.dismail.de (OpenSMTPD) with ESMTP id 4a221b53; Fri, 10 Mar 2023 21:15:53 +0100 (CET) Received: by dismail.de (OpenSMTPD) with ESMTPSA id 8127d5eb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 10 Mar 2023 21:15:52 +0100 (CET) MIME-Version: 1.0 Date: Fri, 10 Mar 2023 20:15:52 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.16.0a From: jbranso@dismail.de Message-ID: <564d5fb289ca2f547ba89fa8f39b7b72@dismail.de> Subject: Re: Brainstorming ideas for define-configuration To: "Liliana Marie Prikler" , "Bruno Victal" , "guix-devel" Cc: "Felix Lechner" , "Maxim Cournoyer" , "=?utf-8?B?THVkb3ZpYyBDb3VydMOocw==?=" In-Reply-To: References: Received-SPF: pass client-ip=78.46.223.134; envelope-from=jbranso@dismail.de; helo=mx1.dismail.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, 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-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=dismail.de header.s=20190914 header.b=BCXnu4X0; 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=pass (policy=reject) header.from=dismail.de ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678479400; a=rsa-sha256; cv=none; b=mpUKu5TTyXQFYpnXseQMRtOM0GCg7+WBBmVpX1L7zvgVuds8rPTYFaRdQ0jfLLJPRVxR7t GRqvgN9e5Yu717gRmLevjRlHAfL3wqWC6132HKmkbBv9wBchnE3TJj1YmeOlBDjI+BVvzi RXLDBfI6ZWHfd1MENtTHdWtRsTbeoNArnpbM7dlFdopgR86b13ei9cIyxw5RCYPbXXbSGr KKEYN6CDyXjEC34rAG/DbUkWTYXj8SpXMpNapM1lbqkBEN79pENc5Hel/w2GVSpcBlNhDw BjsViee+cDFxgeaab3iMlObuyJYqgzo3kS7dkVRu2x+KRvEfNw6GC/KiiIcZ1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678479400; 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=A1Oitl2wris0el17rhF6sfGw1yS4uNBBVNyjqJsyftg=; b=YT9XpCsVevy2oAKydusF12qI4tcGIcDyQ/rpEAh3L2Ub9CDIjfUMIharNaSGHQw5qdkGTa zRdjsSEkVFF+7IKyQ3ZRQOxQ1rlL3QhGutl8iUXmNzS5ohpRAor1uSIe6hLJjDhVZ5CuHO rGuikQ+0wskg8l3sgTUKmmSoXCVzZ1A/06VQHnV1ND0818QlLILq3zS6qCuA7yyaal9frG dC0SESmqI7TbsVDl/vHmn8cJiA3ltPlB1qFUv5IOislKQUSfGIaZgtmE42zC9u4SeR9M5C HeO+ZMGkoaiBsEwuV4IeNDI7pQ7vf/ZKZ2OnTa7SH3XpgqqVZ9B0BukN9XC+QQ== X-Migadu-Spam-Score: -6.13 X-Spam-Score: -6.13 X-Migadu-Queue-Id: D4BE33EEC3 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=dismail.de header.s=20190914 header.b=BCXnu4X0; 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=pass (policy=reject) header.from=dismail.de X-TUID: hRMjoeKufLlH March 9, 2023 3:25 PM, "Liliana Marie Prikler" wrote: > Hi, >=20 >=20Am Donnerstag, dem 09.03.2023 um 02:28 +0000 schrieb Bruno Victal: >=20 >=20I smell bad code ahead. >=20 >>=20We 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). >>=20 >>=20--8<---------------cut here---------------start------------->8--- >> ;; the common case >> (define-configuration foo-configuration >> (name >> string >> "Lorem ipsum...") >>=20 >>=20;; ... >>=20 >>=20(validator procname)) >>=20 >>=20;; [bonus] Simpler configurations that only care for mutually- >> exclusive fields >> (define-configuration foo-configuration >> (name >> string >> "Lorem ipsum...") >>=20 >>=20(title >> string >> "Lorem ipsum..." >> (conflicts 'name))) >> --8<---------------cut here---------------end--------------->8--- >=20 >=20Instead of providing both a name field and a title field, you might > provide a field that can either be a name or a title or allow an even > more powerful value type as long as it makes sense. While I would agree that a guix service writer should avoid mutually exclusive fieldnames and instead prefer mutually exclusive records (and 95% of that time that will work), but may we examine it from a user's perspective? How does the service writer differentiate from a string title or string name? Suppose that you want to respond to a king's rudeness. You can secretly insult him or obviously insult him: =3D=3D=3DMutually exclusive records=3D=3D=3D, which are better from a mai= ntainer's perspective, but perhaps cause the user to write more scheme: "..your traitor brother. Maybe I=E2=80=99ll feed him to wolves after I=E2= =80=99ve caught him. Did I tell you, I intend to challenge him to single combat?" (insult-configuration (response (secret-insult-configuration (secret-insult =E2=80=9CI should like to see that, Your Grace.=E2= =80=9D)))) OR "You can't insult me." (insult-configuration (response (obvious-insult-configuration (obvious-insult "We've had vicious kings and we've had idiot kings, but I don't know if we've ever been cursed with a vicious idiot for a king!")))) =3D=3D=3DMutually exclusive fieldnames=3D=3D=3D "I am the KING!" (insult-configuration (secret-insult "Any man who must say, 'I am the king' is no true king. I'll show you that after I've won your war."))) OR "You are Kingsguard!" (insult-configuration (obvious-insult "...F*ck the King.")))) These examples are pretty wonky I will admit, but I really like an option of having mutually exclusive fieldnames. Having said all of th= is, I will agree that that mutually exclusive fieldnames are a bit like "goto= " in C. You really should never use them, unless you absolutely have to. Thanks, Joshua P.S. I thought about not sending this email, then realized that someone might find it funny. Sorry if it wastes your time. :(