From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id KD7mDcwcQmIwqgAAgWs5BA (envelope-from ) for ; Mon, 28 Mar 2022 22:38:36 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id +C0aBswcQmIvEgEAG6o9tA (envelope-from ) for ; Mon, 28 Mar 2022 22:38:36 +0200 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 9BE3D392F8 for ; Mon, 28 Mar 2022 22:38:35 +0200 (CEST) Received: from localhost ([::1]:49460 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nYw8I-0002nu-EN for larch@yhetil.org; Mon, 28 Mar 2022 16:38:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37932) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYvvt-0005bJ-3O for guix-devel@gnu.org; Mon, 28 Mar 2022 16:25:45 -0400 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]:54801) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nYvvq-0004oJ-9v; Mon, 28 Mar 2022 16:25:44 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id 2A69D2B00517; Mon, 28 Mar 2022 16:25:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 28 Mar 2022 16:25:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= philipmcgrath.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=NPH8JbCxdd4P6jWIAvNRl3z9f93CNwF5Eejk6p PgIgM=; b=Sg92ypKjMqzYaLvL2DMT2ZtANM0eJBHZmnCYT0XOXMPvBC7DuZ6Hke 5SWmRw3mygjR0Z7BWKF071YGx7Lfvcwx+2J7wR4xf4K7Io2NyoJylFI0zTpHRlJt lLIwfqsR6jzVUB9ma6aGaK58TdyO6C962DI/M/TfoAOZPsowzTy4yWRHHTwWStv8 JypI8fCqFMfISqZhJQWBVRcIe2Diryetq8afZnXnjBqKTYePjD2g7+aXCvCb2FFq Zeg61cDJULBSHFMoTVHUfB4JZ+2pNGsVLrEjHWZZuQQT2w2JbZFZDFtPKcBUBiaP 1Y0VWzrCBnMywit/S9SUkRVXUmb7egPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=NPH8JbCxdd4P6jWIAvNRl3z9f93CNwF5Eejk6pPgI gM=; b=SBHYMFiHHr6A8cfmLaVtN5wPmozxKZOPOavKRcaireHPi0idT2ufosZU1 JcGCcFLLbqoN4JMBD50Iwiiu36ngSYnQuiWqW7tIkawcm9hvVcS+5WMIvznmDrPx UF5YjVhq1U7l9yOb9yBqnK1P0/if/HZjaMUi6Z+I3d9lbSevZJbmFuXEnkNRrGkA GU45zIzjNdlBeKns859uMCe06ryK2IlwrAlcyWySzwENOATGSspb5vZ3ZHvizDzv r8UipYJi2JwpZz9QCteB6hMW3MucjINeH1hqnTZs8cnX0Jho7+d9fY0oXRYvKVRf ESMJdw3kOOFDqiqA5bc39+GN733uQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudehjedgudehtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefrhhhi lhhiphcuofgtifhrrghthhcuoehphhhilhhiphesphhhihhlihhpmhgtghhrrghthhdrtg homheqnecuggftrfgrthhtvghrnhepueeuudehuddvhfdvieduhfegvdefteeuheegffeu geffueeijeeuleeufeevvddunecuffhomhgrihhnpeguihhstghouhhrshgvrdhgrhhouh hppdhnvghurdgvughupdhrrggtkhgvthdqlhgrnhhgrdhorhhgnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpsehphhhilhhiph hmtghgrhgrthhhrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 28 Mar 2022 16:25:34 -0400 (EDT) Message-ID: Date: Mon, 28 Mar 2022 16:25:33 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: better error messages through assertions Content-Language: en-US To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= References: <87ilthoxvu.fsf@elephly.net> <87k0dv6ahq.fsf@elephly.net> <87mtibdu5l.fsf@gnu.org> <2205364.8dmU9V6fpu@bastet> <87cziy2hq0.fsf@gnu.org> From: Philip McGrath In-Reply-To: <87cziy2hq0.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=64.147.123.27; envelope-from=philip@philipmcgrath.com; helo=wnew2-smtp.messagingengine.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URI_DOTEDU=1.246 autolearn=no 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: , Cc: Ricardo Wurmus , guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1648499915; 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=NPH8JbCxdd4P6jWIAvNRl3z9f93CNwF5Eejk6pPgIgM=; b=q2pTdy9NboW7FEsaljcnlvYr2w0wUl5MuIB+BKfCMYpQBUVAb0YV8i252C2umh7QPl43fA hs282kLdVXHDiiCAbW8Mi7cQhi7G7V9rrfQmwSQ/hf6NJMb2vZxWT3n4fpJL2+xa+JRZoX 9NMdvVTO0YVjn5XtR/0jg54iXtTyGvMpnxY00lhEXGk+4ubDl4guQE0pFf7bPXiXuTvYfi zvid8pAvzcHfjHiSCqXRBFdWE9E45mMa2PNtAEZDnlN/TzmuyYSvbnY8kUgVwQpFT7Qnyx GBn7NCsc7uje/Oh0Dss1UONkg2vuImCnypaErBdJlqoBH3bdLKt2OVeIV6HOBQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648499915; a=rsa-sha256; cv=none; b=lG+tOT5TRgIVgewFy8hV8FeuAtLx5p7nFdmLlFS8UR30hr/0fQXQXgwedLMPh5tjTuSzqG COeE8KrEfkfrG4VZrGVqrx3uGoaUEC1LE9R4G6S5XIdQxdBKwIrzkWYeLI3x9WJMWojFbO kNlpYZuH5l2GdTQKcHk2SKzBZXW+hn34SWa7S3GB5UA0cbYtzwtcZ1cpmIRUYOnRo6JijZ Jhejirc5vxhzMeBTzRmk30jcZSeKIfT1o4AKmcG/c6T0wJIlkx4a12NsffOIeNig1IM2gE TtvKHTjc6xcVOKD7ssq7tbb9fcgeTwl/3FWyJpUocJygNnwbWKC1aNYfZi+rKg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=Sg92ypKj; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm3 header.b=SBHYMFiH; 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: 0.74 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm1 header.b=Sg92ypKj; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm3 header.b=SBHYMFiH; 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: 9BE3D392F8 X-Spam-Score: 0.74 X-Migadu-Scanner: scn0.migadu.com X-TUID: D4DnQTr1sjGO Hi, On 3/7/22 05:13, Ludovic Courtès wrote: > Hi Philip, > > Philip McGrath skribis: > >> Racket's state-of-the-art contract system has many features and nuances. I *do >> not* think anyone should try to implement them all in one fell swoop. I'm >> hoping there's a way to implement your simple assertions with only a modest >> amount of overhead that will provide the right base on which to grow the rest >> of a contract system. In the short term, the advantage over: >> >>> (assert-type (listof service?) services >>> "SERVICES must be a list of values.") >> >> is that you don't have to write error messages by hand. >> >> You need two types of values: >> >> 1. Contracts, recognized by `contract?`; and >> 2. Blame objects, recognized by `blame?`. > > [...] > > Thanks for the explanation and references! I had briefly looked at > Racket’s contract API in the past but your message gave a clearer view > of how this all fits together. > I'm glad this is something Guix people are interested in! >> I would love to have contracts in Guix, even very rudimentary contracts. If >> it's something the community more generally would be interested in, I'd be >> glad to help as much as I can. > > It’d be great to benefit from your expertise here. Like you wrote, I > think we should start with a simple contract system, certainly simpler > than Racket’s, and build from there. > > If you’re willing and able to spend time prototyping this, that’s great. > :-) > I'm interested in putting together a prototype. I've taken my own suggestion and asked the Racket community for more advice: https://racket.discourse.group/t/advice-on-implementing-a-contract-system/832 To quote the end of my last message there, > The tl;dr of all that is that `(guix records)` seems to ultimately call for "indy-dependent" contracts[1]. > > On the one hand, the distinction between "indy-dependent" `->i`[2] and "lax-dependent" `->d`[3] is exactly the sort of hard-learned lesson that I hope the Guix community can draw from Racket's decades of experience. > > On the other hand, I'm increasingly intrigued by the idea of starting with forms along the lines of `invariant-assertion`[4] and `struct-guard/c`[5] and truly sticking to flat contracts to start with, leaving all the higher-order complexity for another day. I'm thinking that a reasonable place to start might be to implement a `contract->sanitizer` form that would allow using contracts to create sanitizers, ideally with no changes to `(guix records)`. In addition to the questions about contract system design, I realized I have a few questions about Guix/Guile that would be relevant when starting a prototype. What is the preferred mechanism for exceptions? I know about: * (rnrs exceptions) * (ice-9 exceptions) * (srfi srfi-34) * (srfi srfi-35) and IIRC I've seen more than one of them used in the Guix codebase. Likewise, what record system should I use? I think the answer should *not* be (guix records): instead, I think (guix records) should eventually use (guix contracts). But should I use: * (rnrs records syntactic) * (rnrs records procedural) * (srfi srfi-9) * (oop goops) Of those, I'm most familiar with R6RS records. I know (guix records) is implemented on top of (srfi srfi-9), though I vaguely remember some discussion about potentially changing that. Also, I don't know much about how the "abi" aspect of (guix records) works and what types of changes there would trigger rebuilds. (Though, again, I hope no changes would be needed for the proof-of-concept phase.) Finally, when I looked again at the example at the top of this thread: On 2/14/22 17:32, Ricardo Wurmus wrote: > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): > --8<---------------cut here---------------end--------------->8--- > > As you can probably tell easily by looking at this message, the > “service” field of the operating system configuration looked something > like this: > > (services (append (list a b c %desktop-services) #;oops)) > > instead of this > > (services (append (list a b c) %desktop-services)) > > This is because INSTANTIATE-MISSING-SERVICES — and FOLD-SERVICES, and > many more — assumes that it is only passed a plain list of services. It > then proceeds to call SERVICE-KIND on what may or may not be a service. Another problem here seems to be the fault of (srfi srfi-9). For example: ``` $ guile GNU Guile 3.0.8 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> ,use (srfi srfi-9) scheme@(guile-user)> (define-record-type container (make-container contents) container? (contents container-contents)) scheme@(guile-user)> (container-contents '()) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): () Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> ,bt In current input: 3:0 1 (_) In ice-9/boot-9.scm: 1685:16 0 (raise-exception _ #:continuable? _) ``` It seems like `container-contents` and other field accessors ought to check their arguments with `container?` (or the applicable predicate) and not leave error reporting to `struct-vtable`. Perhaps this could be fixed in the (guix records) layer? -Philip [1]: https://www2.ccs.neu.edu/racket/pubs/popl11-dfff.pdf [2]: https://docs.racket-lang.org/reference/function-contracts.html#%28form._%28%28lib._racket%2Fcontract%2Fbase..rkt%29._-~3ei%29%29 [3]: https://docs.racket-lang.org/reference/function-contracts.html#%28form._%28%28lib._racket%2Fcontract%2Fbase..rkt%29._-~3ed%29%29 [4]: https://docs.racket-lang.org/reference/attaching-contracts-to-values.html#%28form._%28%28lib._racket%2Fcontract%2Fprivate%25in2Fbase..rkt%29._invariant-assertion%29%29 [5]: https://docs.racket-lang.org/reference/attaching-contracts-to-values.html#%28form._%28%28lib._racket%2Fcontract%2Fbase..rkt%29._struct-guard%2Fc%29%29