From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id AMTwGKS7N2YnAwEA62LTzQ:P1 (envelope-from ) for ; Sun, 05 May 2024 19:02:28 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id AMTwGKS7N2YnAwEA62LTzQ (envelope-from ) for ; Sun, 05 May 2024 19:02:28 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b=WTjeUUTR; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1714928548; a=rsa-sha256; cv=none; b=UzYjH1+ZQ55kwjEpN2G31dASI4Jk8bXyN4kSIGxuOCOYW9onLd/aCZQssb3X9CKca1g6gl YUq7GpaeeHa41CdEqv+YbHwpF9RATSgid23XCUBRoi8TCNVnHAJrK1vqWkNQvKzmj6dWV2 L/C3nfXrWRp0LTYd1s+ELV7UnZvcE5Kz/OQCJiQiNbep0225slRu2hxMlFKrN5QvbNlQGr Rj8otkfyZEZ18r3pLjT7wKGPvedDhIssdHbLcBHNVyG8C9yJ6H22Lx1vU4STguEXFidniO LARupW77GhzhSdanNa9TusrfUD6OIRrOxOon1ARkYNzI4ar7bku27gFDtz9kOQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b=WTjeUUTR; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1714928548; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=j8vPMAcbRj6/fUDIEBcKjqvQmCIGwkyLBq53IqZyl7Q=; b=o4qburjnvRPwHrJ4Jhk/JhmdfijguiHLKwTb/YW29by3kgaPNkVxuYALSKGlDWbCL4sZmc irSm1NzkS0cnbhEdzWvlcZPFVP9zBbptCZC9nbJZFb1Pv2u34HeRE6nmQT+kPvruKCow1E v1Ya8S5F58+7FTMz3p42eStbx7wpmu3fTWpnQYBn5OecgFMYbmufPkj/eE6OzJ/JriaOs6 pi+wglrTKHWXhsbBC5PVRqWVfQvuYG0IKq489uYrGN+mfxAXObwWvJzq266iNM9Nrnldfe wXe88iwt9isxh+rb4Nzr7b4C2HGNlK1iRnWa+UpF/p7AtuG00TJSJZuHTv8wIA== 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 41DC821C71 for ; Sun, 5 May 2024 19:02:28 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s3fFU-0007dO-Sy; Sun, 05 May 2024 13:02:04 -0400 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 1s3fFS-0007d7-O1 for help-guix@gnu.org; Sun, 05 May 2024 13:02:02 -0400 Received: from mail-108-mta152.mxroute.com ([136.175.108.152]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s3fFQ-0000DQ-Sn for help-guix@gnu.org; Sun, 05 May 2024 13:02:02 -0400 Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta152.mxroute.com (ZoneMTA) with ESMTPSA id 18f49b4831d0008ca2.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sun, 05 May 2024 17:01:57 +0000 X-Zone-Loop: 39401b9a09ae8a8e00db2b8d9055769fecdef93f625e X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=freakingpenguin.com; s=x; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=j8vPMAcbRj6/fUDIEBcKjqvQmCIGwkyLBq53IqZyl7Q=; b=WTjeUUTRL+Uzou3bPX8xnafHN+ 2fh4MkMETg6K73Zez+v6VqvvKRUQ0TuyMKv6ZSiXAFg5IU/l/wIlEf/LEZPrf09i/q1Fdez/v4y9r qwzKbptTB+ofVuY0fyv6n4mEJIoCnjGmdMdoGvfd6WSK6+B4xTnckp8bjuKJ/Sh3unjbrv5mxupW5 jT9pnQ/QALaKSYMUJ+OKFNc0o9D9O772CjyIMXBlkUAGs2ix2tYhCmrHo98SUbfufuPMSD9fSyrEp +KnS/v3pzabt9Jd/9bWfWv0scTyilSsX8JNy2bfJEZ1oPUiJBqQgT5kCk2YC9AlshKsrZgbTwhClm dPDR9mcA==; From: Richard Sent To: help-guix@gnu.org Subject: Validating an entire record-type* at value creation Date: Sun, 05 May 2024 13:01:50 -0400 Message-ID: <871q6gw5tt.fsf@freakingpenguin.com> MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: richard@freakingpenguin.com Received-SPF: pass client-ip=136.175.108.152; envelope-from=richard@freakingpenguin.com; helo=mail-108-mta152.mxroute.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: help-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 41DC821C71 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -6.39 X-Spam-Score: -6.39 X-TUID: IpXgM3W2TY19 Hi Guix! Does define-record-type* support creating a validator/sanitzer that validates the entire record during creation? I know you can create sanitzers for individual fields (example below from the docstring). --8<---------------cut here---------------start------------->8--- A field can also have an associated \"sanitizer\", which is a procedure that takes a user-supplied field value and returns a \"sanitized\" value for the field: (define-record-type* thing make-thing thing? this-thing (name thing-name (sanitize (lambda (value) (cond ((string? value) value) ((symbol? value) (symbol->string value)) (else (throw 'bad! value))))))) --8<---------------cut here---------------end--------------->8--- I think it would be valuable to validate fields in relation to each other. For example, verifying that mutually exclusive fields aren't all set to #t. However before I actually open this as a bug or post about it on guix-devel I want to check if such a thing already exists. Or if there's an equivalent method to achieve a similar result that's already used in the code. I imagine in general we don't want too many records that can have mutually exclusive fields. However, (I believe) that already exists in the current code base. For example, the file-system record has both needed-for-boot? and dependencies, but if mount-at-boot? is set dependencies is ignored. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.