From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id IBtuOMh6dmFfCQEAgWs5BA (envelope-from ) for ; Mon, 25 Oct 2021 11:37:12 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id WGsINMh6dmEWJQAAbx9fmQ (envelope-from ) for ; Mon, 25 Oct 2021 09:37:12 +0000 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 43BB299FC for ; Mon, 25 Oct 2021 11:37:12 +0200 (CEST) Received: from localhost ([::1]:60220 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mewPn-0005Zq-FU for larch@yhetil.org; Mon, 25 Oct 2021 05:37:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mewPe-0005YT-LS for bug-guix@gnu.org; Mon, 25 Oct 2021 05:37:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:58362) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mewPe-00068M-Bi for bug-guix@gnu.org; Mon, 25 Oct 2021 05:37:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mewPd-0007aU-VK for bug-guix@gnu.org; Mon, 25 Oct 2021 05:37:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#51383: noobie way of incorrectly using (guix records) Resent-From: Joshua Branson Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 25 Oct 2021 09:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51383 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: zimoun Cc: 51383@debbugs.gnu.org Received: via spool by 51383-submit@debbugs.gnu.org id=B51383.163515461729155 (code B ref 51383); Mon, 25 Oct 2021 09:37:01 +0000 Received: (at 51383) by debbugs.gnu.org; 25 Oct 2021 09:36:57 +0000 Received: from localhost ([127.0.0.1]:41675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mewPY-0007aA-O6 for submit@debbugs.gnu.org; Mon, 25 Oct 2021 05:36:57 -0400 Received: from mx1.dismail.de ([78.46.223.134]:36278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mewPS-0007Zo-C0 for 51383@debbugs.gnu.org; Mon, 25 Oct 2021 05:36:54 -0400 Received: from mx1.dismail.de (localhost [127.0.0.1]) by mx1.dismail.de (OpenSMTPD) with ESMTP id 0f8342fd; Mon, 25 Oct 2021 11:36:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dismail.de; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=20190914; bh=Knwd5RsY 1wDVvRd/yTaAh+MdoXZeQitonR1mhR5FOi8=; b=jubE3xEoU1R46Oor+s9fU/da URy+kdRVycwBNEUAfuS9ifK/VCi2KDCz/IxEgw01wpZ0jKkpjWcCzS+Ce1mqkxMp of/icKjRpJbpeSdmXxPPCHYfgT2XyqjBUDQDrN4NSo+QM5jOSHv8hBF4IMQnfw9x c89n99I9BjYXamt7ZzARvErqJtI44qFUm8eTZLD6RT/r7qncGuAewBx/YxNHMEMs u/jqFCUGA5dtRz5eOwu+JNH3vFR+J1CM44nDR56GlMUHad1JmIkyFNFiguXTZrDA DsPU94BwCc2RIVnA8gKVdYCDQ92HWMNXjvrd6Pp/cS3m4wqQz7f5SIu/y5YtqA== Received: from smtp2.dismail.de ( [10.240.26.12]) by mx1.dismail.de (OpenSMTPD) with ESMTP id 6b4d47d2; Mon, 25 Oct 2021 11:36:43 +0200 (CEST) Received: from smtp2.dismail.de (localhost [127.0.0.1]) by smtp2.dismail.de (OpenSMTPD) with ESMTP id 19f1ef63; Mon, 25 Oct 2021 11:36:43 +0200 (CEST) Received: by dismail.de (OpenSMTPD) with ESMTPSA id 004c2afc (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Mon, 25 Oct 2021 11:36:42 +0200 (CEST) References: <87zgqxiq91.fsf@dismail.de> <864k95a6je.fsf@gmail.com> Date: Mon, 25 Oct 2021 05:36:39 -0400 In-Reply-To: <864k95a6je.fsf@gmail.com> (zimoun's message of "Mon, 25 Oct 2021 09:48:53 +0200") Message-ID: <87bl3dwimw.fsf@dismail.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" Reply-to: Joshua Branson From: Joshua Branson via Bug reports for GNU Guix X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1635154632; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=6EQl2wDTanxbzimB2tIaE5R4oMxpb70nXyFvJ0IXQN8=; b=Zc5Pk4cdBWjaUdIl6VsM+YNIKuP1Fzs2VeTSQ2K3+Q9D/SCl43iW09MG4MWUhQYV9Yf90H pyc+RFP+CRTmaG/ljjJaGKanrrghRCT6yp3qf5Q7Yq4927/5+JUO4TIsCUjHitiWj/Udbw QDHKf71F7SqcpGZG3GxRu1nQMYy22DpbHEQvLoBGVp4lghpACzcOpHZ8266nzejvrZPGng aB90FAtLU7q0JPpiSHvG0zDgeq4vElmBMQinsZXKJ9vTiS7UR0XBeOXkeSrqA5Lc0bVq7C D/DZLvMNIQ5pnNZybHE/5EUTOInbSfO+AR+a/kPly+k3LaLjuQyIQ8Wy5ITUgw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1635154632; a=rsa-sha256; cv=none; b=FTamPwwOK3dkYyxcY503u2KAgu8gbrmlzYHW75bUfkcEeno5pQLAnSYGi30LWbE+21SHGs pBseT+mNEf6o98AIoGe7W9R3xWrHt3SoSbmBy1nawkrPdPnWI6lpsD/nUH/EgtKO/KAmKo hwUvJ+vzBql85w8sEbfqF2JtM/xZpjj/vMzscWLfawRzPWcDMBL7tjDKHH95je7AVwEINr 9JEviYPW+O6m2CdTkyvqtQtJN2OVk1Z/PVPPstlVxdt42mdYbfObzRjG7fyolKAkg8yYYt mZbHWteFMfHA9YUKEMxkN6dgrrJJl2nVrmHrjIXd4AoinBXhu90OnSW+dUvw7g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=dismail.de header.s=20190914 header.b=jubE3xEo; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -3.43 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=dismail.de header.s=20190914 header.b=jubE3xEo; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 43BB299FC X-Spam-Score: -3.43 X-Migadu-Scanner: scn1.migadu.com X-TUID: 4TEB2fbW3Rmy zimoun writes: > Hi, > > On Mon, 25 Oct 2021 at 02:15, Joshua Branson via Bug reports for GNU Guix= wrote: > >> So I made a pretty noobie-like mistake a few minutes ago. When one >> tries to make a (record-configuration), he invariably create an >> infinite number of records. The guile compiler eventually runs out >> of memory and stops compiling. >> >> (use-modules (guix records)) >> >> (define-record-type* >> record-configuration make-record-configuration >> record-configuration? >> (command record-configuration-command >> ;; the error is here is on the next line >> (default (record-configuration))))=20=20 >> >> (record-configuration) > > This is defined by creating recursively another > instance. Thus, It is expected that it does not work, no? Yes that is correct. I am only slightly annoyed at the lack of a helpful error message. Thanks for helping me clarify my point. I was working on a rather large collection of guix records for an opensmtpd service configuration. The file is about 1,000 lines long. Trying to find that error without a helpful error message was slightly annoying. I agree that the fault was mine and I do not believe the bug can be fixed. Rather it would be nice to have a more helpful error message. It could be possible that guile offers such flexibility in general that the compiler is unable to provide good error messages in all situations. I am just hoping for a better error message somewhere, ether in the compiler or something in the (define-syntax-record* macro. Is it possible to get a better error message? Is that a thing worth pursuing? Or is the fix worse than the present condition? > Reading the doc, > > 1. what do you want to achieve? > 2. what does it appear to you buggy? Or what do you think the > =E2=80=9Ccorrect=E2=80=9D behaviour should be? > > (define-syntax define-record-type* > (lambda (s) > "Define the given record type such that an additional \"syntactic > constructor\" is defined, which allows instances to be constructed with n= amed > field initializers, =C3=A0 la SRFI-35, as well as default values. An exa= mple use > may look like this: > > (define-record-type* thing make-thing > thing? > this-thing > (name thing-name (default \"chbouib\")) > (port thing-port > (default (current-output-port)) (thunked)) > (loc thing-location (innate) (default (current-source-location)))) > > This example defines a macro 'thing' that can be used to instantiate reco= rds > of this type: > > (thing > (name \"foo\") > (port (current-error-port))) > > The value of 'name' or 'port' could as well be omitted, in which case the > default value specified in the 'define-record-type*' form is used: > > (thing) > > The 'port' field is \"thunked\", meaning that calls like '(thing-port x)'= will > actually compute the field's value in the current dynamic extent, which is > useful when referring to fluids in a field's value. Furthermore, that th= unk > can access the record it belongs to via the 'this-thing' identifier. > > A field can also be marked as \"delayed\" instead of \"thunked\", in which > case its value is effectively wrapped in a (delay =E2=80=A6) form. > > A field can also have an associated \"sanitizer\", which is a procedure t= hat > takes a user-supplied field value and returns a \"sanitized\" value for t= he > 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))))))) > > It is possible to copy an object 'x' created with 'thing' like this: > > (thing (inherit x) (name \"bar\")) > > This expression returns a new object equal to 'x' except for its 'name' > field and its 'loc' field---the latter is marked as \"innate\", so it is = not > inherited." > > > (Argh, I do not know how to read/display the docstring from the REPL, > another annoying* story. :-)) Do you know if the above guix records are in the guix manual? If not, I'll probably add them. > >> This is not possible with (srfi sfri-9) >> >> (use-modules (srfi srfi-9)) >> >> (define-record-type >> (make-employee name age (make-employeee 5 5 5)) >> employee? >> (name employee-name) >> (age employee-age set-employee-age!) >> (salary employee-salary set-employee-salary!)) > > Well, =E2=80=99(guix records)=E2=80=99 allows to do more than =E2=80=99(s= rfi srfi-9)=E2=80=99. Amen for that! (guix records) are awesome! > Aside, I > am not convinced that this latter snippet is similar than the former > previous one. I was just trying to see if I could produce a similar issue for the guile compiler via only using (srfi srfi-9). Apparently I cannot. > Cheers, > simon > > *annoying REPL, I get: > > scheme@(guix-user)> ,describe define-record-type* > While executing meta-command: > Syntax error: > unknown file:79:10: source expression failed to match any pattern in form= define-record-type* try (use-modules (guix records))...though you probably already did that. What about ,m (guix records) ? --=20 Joshua Branson (jab in #guix) Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as you help enough other people get what they want." - Zig Ziglar =20=20