From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id IHy8EHkwS2P2twAAbAwnHQ (envelope-from ) for ; Sun, 16 Oct 2022 00:13:13 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id ONbWEHkwS2NSkwAAauVa8A (envelope-from ) for ; Sun, 16 Oct 2022 00:13:13 +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 EF3D62FF53 for ; Sun, 16 Oct 2022 00:13:12 +0200 (CEST) Received: from localhost ([::1]:47658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojpP5-0007w0-SZ for larch@yhetil.org; Sat, 15 Oct 2022 18:13:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54668) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojpOw-0007vb-Ao for guix-patches@gnu.org; Sat, 15 Oct 2022 18:13:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:43672) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ojpOv-0000mX-W2 for guix-patches@gnu.org; Sat, 15 Oct 2022 18:13:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ojpOv-0000od-Hm for guix-patches@gnu.org; Sat, 15 Oct 2022 18:13:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#58231] [PATCH 2/2] packages: Raise an exception for invalid 'license' values. Resent-From: Philip McGrath Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 15 Oct 2022 22:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58231 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: zimoun , Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 58231@debbugs.gnu.org Received: via spool by 58231-submit@debbugs.gnu.org id=B58231.16658719573100 (code B ref 58231); Sat, 15 Oct 2022 22:13:01 +0000 Received: (at 58231) by debbugs.gnu.org; 15 Oct 2022 22:12:37 +0000 Received: from localhost ([127.0.0.1]:42750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojpOW-0000nw-Pv for submit@debbugs.gnu.org; Sat, 15 Oct 2022 18:12:37 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:56255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojpOU-0000ng-4F for 58231@debbugs.gnu.org; Sat, 15 Oct 2022 18:12:35 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 12F6C5C007D; Sat, 15 Oct 2022 18:12:29 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 15 Oct 2022 18:12:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= philipmcgrath.com; h=cc:cc: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=fm3; t=1665871949; x= 1665958349; bh=3QRa3bPZVJNhJaB+NRmC07ImcfzWZ3I+G98GsR46M5g=; b=V hyhP5AyUEEGyce5CJZ7MEO63uCjxmMs2KWXAanzmCjIFnnsTBayLRahDD+WGRDav WCD36Gbn6xq8mALecu4RQozvebGGlBj+XfaeWMpCx0dDjBd+TlCqV1QiCGwWaqjp 4iA558wv9/0+TtG1KCaRSZTLhSDa7YZiElwyvCEjPWYt8U/4KZTjXI2OKB46RItu xGtuiyCt+Nkyc+4my9Kg3zzZpQhMNI2O5ZP4Z8V9Nyb4w+aNwzOMZTcq7EeoR3iH 1WBna2yqDZKWw42zmOa67E8YgsF5ObenI7IKGoULOZ1n6xlcn14lYcc8RM3Cy38w 5Q+HeYlf4bQ/2626PwlJg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id: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; t=1665871949; x=1665958349; bh=3QRa3bPZVJNhJaB+NRmC07ImcfzW Z3I+G98GsR46M5g=; b=moYUTI5GWd0aHMA8f5su76hR4AlZyszVre4RTnIVfo4R iMlKAtmo8oNq4hVbW/yiy4mvLHUzCrKuBVNDRqKjLV841SCMBxZlebpPWguuzXad l13jKqDE5nzntXx3zobtyPuEw6c1nLCqWa1dF/39u0rS5A3eu4ZsF3SY1felyaEQ Dj70VgUqYye8Y/ZOPqTNQloWywDOCjzPm4N++4ix2H1qhsf63Uu8DGdEMgVov0Sb d8ti+fWXkD57xU69dcx6/t5hSaXI83iwrXN+8FZu3sIWnKwr5bCusam2yFrUIkOT Q0lFnuSaMf/v3eGNtSWnRDwrOuxR11e+OLVvdzzDhQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeekhedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurhephffvvefufffkjghfgggt sehgtderredttdejnecuhfhrohhmpefrhhhilhhiphcuofgtifhrrghthhcuoehphhhilh hiphesphhhihhlihhpmhgtghhrrghthhdrtghomheqnecuggftrfgrthhtvghrnheptdfg hfegjeeugeehudetleevvdejgeeugeduvdefgfdufffhhfeufedvkeegfffgnecuffhomh grihhnpehgihhtlhgrsgdrtghomhdpughishgtohhurhhsvgdrghhrohhuphdprggtmhdr ohhrghdpghhithhhuhgsrdhiohdpuhhtrghhrdgvughupdihohhuthhusggvrdgtohhmpd hgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepphhhihhlihhpsehphhhilhhiphhmtghgrhgrthhhrdgtohhm X-ME-Proxy: Feedback-ID: i2b1146f3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 15 Oct 2022 18:12:28 -0400 (EDT) From: Philip McGrath Date: Sat, 15 Oct 2022 18:12:19 -0400 Message-ID: <3209515.oiGErgHkdL@bastet> In-Reply-To: <87mta320kf.fsf@gnu.org> References: <20221001162058.8214-1-ludo@gnu.org> <87tu4crnad.fsf@gmail.com> <87mta320kf.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6456230.G0QQBjFxQf"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" 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=1665871993; 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: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=3QRa3bPZVJNhJaB+NRmC07ImcfzWZ3I+G98GsR46M5g=; b=fp/geIyNWKmBAcXkMxHZqc6SRw0dtst4fQ5EY8SWgghcyjNUAgJ5zqZ0rj7pBrC0ngab9v +PH8GA4CQFWZsLJY0bEScnjGckxeaUpRdLC++D1fTouCnu2pcTi1cFlCjJI+AGa0xRlvlT g6Jd9C3u+DhiuyzZ+sev2OT88gRvHVndQfN4IOOthyeB1hcTmicXZYTm8OX1sowft/c4Ar A2J5N9bnTSUQ9lQ35peE+KUTeq1Li6znVm6JuZO1PmPXUJz51qZdfimcyt7wDgBzpeZyKP 8uw/L6kcVn/k7fbWEnnBKFPRVlluMtqaE91MhJKVsAz3+BIaG6PNxKigdkBYmw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665871993; a=rsa-sha256; cv=none; b=ZOk4mdezYiOgiCDpyFzETufWVAvR2R8c9R6jcnzk9PoaOp16iTZ01aqX8XOWxClx/MrdaR guaMv7FBWIk+4ituL+1RW0/eaP8JYZR/IXAeyL45Lre89B+RWSf8ozGxxmrUcak89c3EEq dzbWjDxkPBJVWUquVoRguAPBhlBAiOzCkLFN6cBi+y/JQKUTk5UXg/Y8ev6Q8nXCRRy9d9 FbSYjT8h9theWIXw/mLmXR3UGslBOtMps9bmnNlm3izaEjbulU7R+HflEhuQ8FRgfM6+7l 6ordxJ4ktcv8/T4yK0Ajj9dnshmcGqN8SNjrxT0BAI+0SNG5vx1R4GJjHyJH8w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm3 header.b="V hyhP5A"; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm3 header.b=moYUTI5G; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.30 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=fm3 header.b="V hyhP5A"; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm3 header.b=moYUTI5G; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: EF3D62FF53 X-Spam-Score: -2.30 X-Migadu-Scanner: scn0.migadu.com X-TUID: TK8Dmvs3Ub6O --nextPart6456230.G0QQBjFxQf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Philip McGrath Cc: 58231@debbugs.gnu.org Date: Sat, 15 Oct 2022 18:12:19 -0400 Message-ID: <3209515.oiGErgHkdL@bastet> In-Reply-To: <87mta320kf.fsf@gnu.org> Hi, On Monday, October 10, 2022 10:52:16 AM EDT Ludovic Court=C3=A8s wrote: > Hi, >=20 > zimoun skribis: > > On sam., 01 oct. 2022 at 18:20, Ludovic Court=C3=A8s wro= te: > >> ;; A package. > >> (define-record-type* > >> package make-package > >> @@ -574,7 +607,8 @@ (define-record-type* > >> (sanitize validate-texinfo)) ; one-line descript= ion > >> (description package-description > >> (sanitize validate-texinfo)) ; one or two > >> paragraphs > >> - (license package-license) ; (list of) > >> + (license package-license ; (list of) > >> + (sanitize validate-license)) > >> (home-page package-home-page) > >> (supported-systems package-supported-systems ; list of strings > >> =20 > >> (default %supported-systems)) > >=20 > > This change is the core, IIUC. The question is: does it make sense to > > have something similar for all the fields? > >=20 > > For instance, the fields =E2=80=99name=E2=80=99 and =E2=80=99verson=E2= =80=99 are expected to be =E2=80=99string=E2=80=99 > > and could be similarly checked? >=20 > I think eventually we should have contracts rather than home-made type > checks like this (Cc=E2=80=99ing Philip). >=20 Definitely agreed that contracts are The Right Thing, though `string?` by itself would in fact be a contract. I'm planning to get back to trying to write a basic `(guix contracts)` libr= ary once I've finished my current project, a `racket-build-system` (for which I= 've finally started writing code, as opposed to planning and shaving many yaks: https://gitlab.com/philip1/guix-racket-experiment/). I had started a fairly direct port of Racket's contract system, though with= the intention of starting out with as little as possible. I think I'd more or l= ess finished the representation of "blame" objects. However, one thing that gave me pause was some of the advice I got on . Matthias Felleisen wrote: > I will also say that as much as I like ho [higher-order] contracts and u= se them > extensively, > making everything a function is bad for any future optimization. >=20 > Michael B[allantyne] Cameron M and I are thinking of designing a hosted c= ontract DSL > on top, via Michael=E2=80=99s special-purpose expanders, and experimentin= g with a > classical optimizer, perhaps even using Leif=E2=80=99s nano-passes (adapt= ed for > syntax of course). Robby Findler, the mastermind of Racket's contract system, later added in p= art: > If I were to get to redo racket/contract, the one big change I'd make is = to > design a (macro-based) DSL for contracts instead of going with a > combinator-based approach. Although you won't need to do it for a > minimum-viable product, the opportunity to, at a later date, look at an > entire contract at compile time and generate better code for it is probab= ly > going to be useful. >=20 > [...] >=20 > That said, you definitely want to allow arbitrary predicates to just be > contracts without having to type a lot of stuff, as that's turned out to = be > super useful. > > [...] This came as a surprise, though the explanations made sense. In Racket, I h= ave a reasonably good sense of how I would implement the kind of DSL they describ= e, either using the framework Ballantyne, King, and Felleisen set out in https://dl.acm.org/doi/abs/10.1145/3428297 (open-access) or manually along = the lines Alexis King explains in a series of blog posts: 1. https://lexi-lambda.github.io/blog/2018/04/15/reimplementing-hackett-s-= type-language-expanding-to-custom-core-forms-in-racket/ 2. https://lexi-lambda.github.io/blog/2018/09/13/custom-core-forms-in-rack= et-part-ii-generalizing-to-arbitrary-expressions-and-internal-definitions/ 3. https://lexi-lambda.github.io/blog/2018/10/06/macroexpand-anywhere-with= =2Dlocal-apply-transformer/ However, I have no idea how to implement such a thing in Guile, and I think= it would be arduous, perhaps even impossible, without `local-expand` and some = of the other features from "Macros that Work Together: Compile-Time Bindings, Partial Expansion, and Definition Contexts" () and relat= ed papers. I'm also wary of shifting the scope from a minimum viable contract library = to what would amount to a research project trying to improve upon the state-of-the-art contract system. So, despite this advice, I still tentatively think I'd start by doing following the Racket contract library very closely. Still, it reinforces my view that we should start small and initially keep the library as `(guix contracts)` or something (though I don't think it should use any Guix specific in its implementation), rather than trying to make a general-purpo= se library, so we could change things fairly freely as we get a more concrete sense of Guix's needs. (In contrast, Racket tries to maintain an extremely high level of source compatibility with even twenty-year-old code.) > However, as you write, we have to pay attention to performance in the > case of packages as it could quickly become too expensive. While I > think it could make sense to have contracts for all the fields of > service configuration records, I think we=E2=80=99ll have to do much less= for > fields. >=20 I'm a little unsure about the specific performance hack in this patch, thou= gh. In either Racket or Chez Scheme, I would expect the compiler constant-fold = an application of a record-type predicate to a known constant identifier. It should be able to do this in all of the scenarios where a macro could interpose, and possibly in additional scenarios made visible through previo= us inlining etc. in the compiler. So I would expect handling special cases in a macro to introduce compile-time cost with no run-time benefit. I would expe= ct this to be covered by "The Guaranteed Optimization Clause of the Macro Writ= er's Bill of Rights": https://www.youtube.com/watch?v=3DLIEX3tUliHw =46rom Andy Wingo's message at https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00230.html I've been hoping roughly the same intuitions apply to Guile records, but ma= ybe that's not true? For example, I'm not sure that Guile allows assignment to imported identifiers for which no assignment appeared in their exporting modules (but the chaos that would ensue from `(set! license:gpl3.0+ "not a license")` seems like a great example of why that's such a useful rule). =2DPhilip --nextPart6456230.G0QQBjFxQf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE9GWrrNY3rqwUFVXPygNjjfo/HHoFAmNLMEMACgkQygNjjfo/ HHoCBQ/9E6AQUfg/54uFx78rXPlypImtCqXr72QIZcRKBhF5r0TJ6YseYSJmL7QX Dl4jZwgMla9PjnF0qXCBohASVpEvMb017gWOmeY4+C3IcYzd+axKAdLw7+7/i4LI 6EaVZYv9eO3USnr9UyOTH/pNiFwL5jnEaJ6zaTwjmIg7iAJOUv/Jpck2sZ5Z59ed 8tly7ZLBXvvIMhZsFNQVk0H68PjjbcFNjUJQbhqjWqrf2clcFippI9jOfF3laJVc oVYuLCC0iJlue9Kqu2sV2mLJ2GMy0czJkAravYggE+9GVUlkiHmFU5vkQWHPOLgt EJhzHrOv0rBhQwYLERe6TcodMm9m//3yGYn4MZSiGyLwhtTFgRVFsI2M8Vy8tOHg LV86V2Fsxy9zqUjPdjW4Z6blnXyTbQGN9wzwvfkJft1hvgFFrwIodZR+H5Oo6riZ unUQCyBFXl23tmwVpi+dUhkCcAzFh3FDdEQ3GJbwmWYqKwcMFHoSxDczDs5USzPS mnH1/9oXBstzK40K9mXaKcQL+WJzA9QD2tcc4rcwun8G4LRv39S2Y2MKGMiYeCYg xnZwZVJsQ0BRphwt7XkB50DZVQbRZGQ1AZuiKANZ/HwUkZiW4Y1AMhTo7EzV+g1l cuW9MDbGYUAoZJv4JLs6mignKrn5oyVpJCAg1ZGgc1QrVyQtCJc= =u1R3 -----END PGP SIGNATURE----- --nextPart6456230.G0QQBjFxQf--