From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id MJ9oLFsw72FAEwEAgWs5BA (envelope-from ) for ; Tue, 25 Jan 2022 00:03:55 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id CC0fKVsw72HQfwEAauVa8A (envelope-from ) for ; Tue, 25 Jan 2022 00:03:55 +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 569A6D2BD for ; Tue, 25 Jan 2022 00:03:55 +0100 (CET) Received: from localhost ([::1]:44074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nC8NO-0007sH-Gm for larch@yhetil.org; Mon, 24 Jan 2022 18:03:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nC8M3-0005vh-JP for guix-devel@gnu.org; Mon, 24 Jan 2022 18:02:33 -0500 Received: from mail-4317.proton.ch ([185.70.43.17]:30992) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nC8Ly-0003QR-ID for guix-devel@gnu.org; Mon, 24 Jan 2022 18:02:30 -0500 Date: Mon, 24 Jan 2022 23:02:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail3; t=1643065339; bh=rQ60yZH3ljFSet+nhYvc4PfXAAKAvXcTV9WUt0FTBLo=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc; b=W7MmTc+Cto0A4CXLjftk+FnAZPduFM4+0GadvmnKwEGQVeEOZVCJ1hzG13sVxSE4P tGOcCv3lh087QYNjgZZP+JbgcZtDDuLo++mHgIZYfuVjN1qXe29clDZuteEzeBuRh8 eYI8iyjw+Py1U2P4tvct6KXlERv1stWtJbU1Jq9XPIbugN9BpjI9ocEzq/5IQw4hKu 2b4s6mitkKcNxizeIoyo+Tdsi8nRGJfTr2W2ODBNsNik+gjFAku0Fb1MIRvVyGm7FW ehk/jPjlbztIV8CctdGncmyDOrsuyqmvDlIX89z8eno1hDUunvmrf6q8OaRZFmR5q+ 1IAluU+MDXPwQ== To: =?utf-8?Q?Ludovic_Court=C3=A8s?= From: Attila Lendvai Subject: Re: using an SRFI that is not available in Guile Message-ID: In-Reply-To: <87ilu9rvit.fsf@gnu.org> References: <6vmHCdZdAWsjqvLgmVNEZclQ-JbdRJLfGzLNphX3EbevcslD-_TkMuHA1MwIylOfbe3DkDXYCbx5WT_Q44sC1Qed5MsBUg2xxZKhUbChGGs=@lendvai.name> <87iluhf5ci.fsf@gnu.org> <87o848aua9.fsf@gnu.org> <87ilu9rvit.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.17; envelope-from=attila@lendvai.name; helo=mail-4317.proton.ch 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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: , Reply-To: Attila Lendvai Cc: guix-devel Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1643065435; h=from:from:sender:sender:reply-to: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=rQ60yZH3ljFSet+nhYvc4PfXAAKAvXcTV9WUt0FTBLo=; b=rX2QLT7rGdkhxbEUP/v8Gjmn0fCpYgg2S0gH+86M/TllF9SCfOmTY5Q5SHOrXhxqiA+ZgA nkO0/jnIvhFn5jwz3ZFPrM53rhIokA10dGrYjcWOyEyRyhUPa1LzhQRw3Qh6k3wiEMX2ry BEoMfYxNPoLVyP4MdKKhV+/qivJUgr0EMh83exVb3Ohi4zWBJffLQrXJRMc1Y+W35Y/JVG Q12VqwSp5w79gNDXKeeqOXMU2+yhOELg7T0RehyeDo9wBdyMhcxtlma8bnme6G8CVhCwkA m5WqhtMvW6W3RQJpeA35KPNNJT/KooPcjgwqsodTdDAWahYV6p0hXKUhwBeJ5w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643065435; a=rsa-sha256; cv=none; b=nYENke1eQO23y33zMW9Y2axeDK9VU5ZcdKAG5iwdOIU4REszwKLbO3YKA5DSclnZn0k2tu fuW2lcluIGQvz5Q3D14QT06zO6rxfagdRySkat7i7Ls+AgDU34tPIcjQrWOvtx0wjdfWyI o4yKRJ/5zKW8RzXba1vswGBT+WbKafw+Yews5iClcIlWO1W71Kw0eqJxs5c43gja+rVEFq FQPWqfK6ooi0vC0uIG/QdS9hkPXYTmyim9sAou6MVHipoosFZl1aYAKWi0Bm6DFWFaRldn AHbemQC3euUhrK8z6Ymszx0im+1TDqni1UQycLb6sSGMEB+kyGQju4D3Zd4LAQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lendvai.name header.s=protonmail3 header.b=W7MmTc+C; dmarc=none; 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" X-Migadu-Spam-Score: -5.13 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lendvai.name header.s=protonmail3 header.b=W7MmTc+C; dmarc=none; 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" X-Migadu-Queue-Id: 569A6D2BD X-Spam-Score: -5.13 X-Migadu-Scanner: scn0.migadu.com X-TUID: LyF53+8FByte using *unspecified* here won't work, because Guile's underlying record implementation uses it pretty much for the same purpose: it errors when it encounters *unspecified* as a field value: > (cfg) While compiling expression: Syntax error: unknown file:761:0: %cfg: missing field initializers (threads) in form (%cf= g) so, i'm back to square one: short of another idea, i'll need srfi-189 for this. > I see. The =E2=80=98define-configuration=E2=80=99 macro uses 'disabled as= a way to > indicate fields that have not been user-specified. Would that be of any > help in this context? as discussed already somewhere, regardless of everything else, using 'DISABLED in this context is a bad idea that warrants a patch in itself; it's super confusing and error prone because configs are full of boolean fields. > Another approach would be to use =E2=80=98define-record-type*=E2=80=99 an= d record all > the default values, including those derived from other fields (just like > the default =E2=80=98home-directory=E2=80=99 field of is d= erived from > =E2=80=98name=E2=80=99.) > > Does that make sense? i think it does, but it would enforce a rather different code organization. right now i have a function called APPLY-CONFIG-DEFAULTS that is called at the beginning of each entry point to my service code. it makes sure that the input config is valid, and returns a new config object that has the defaults filled in. it has corss-referenced local variables and even some local functions. assuming that the evaluation of the default value forms of thunked fields is delayed until their first access, then forcing this logic into multiple default forms is possible, but i'd rather not if i can avoid it. also, i do want to have the goodies of DEFINE-CONFIGURATION. i used to use DEFINE-RECORD* before, prior to knowing that D-C was a thing. then i rewrote my code to use D-C. maybe i can smarten up DEFINE-CONFIGURATION to (optionally?) use thunked fields? i'll need to sleep on it. Ludovic, you're not too happy about the use of extra dependencies here, right? if so, can you please advise whether i can proceed with giving srfi-189 a try and see what it looks like (i.e. it's not off the table to get it accepted)? or do you have any other ideas? -- =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- Before you speak, let your words pass through three gates: At the first gate, ask yourself =E2=80=98Is is true?=E2=80=99 At the second gate ask, =E2=80=98Is it necessary?=E2=80=99 At the third gate ask, =E2=80=98Is it kind?=E2=80=99 =09=E2=80=94 Sufi saying