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 cA1HLCNE2WHOFAAAgWs5BA (envelope-from ) for ; Sat, 08 Jan 2022 08:58:27 +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 eGTwKCNE2WFVCAEAauVa8A (envelope-from ) for ; Sat, 08 Jan 2022 08:58:27 +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 0499E34122 for ; Sat, 8 Jan 2022 08:58:27 +0100 (CET) Received: from localhost ([::1]:59904 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n66cL-0003RZ-T5 for larch@yhetil.org; Sat, 08 Jan 2022 02:58:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60046) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n65io-0003RL-IN for guix-patches@gnu.org; Sat, 08 Jan 2022 02:01:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:53342) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n65io-00073j-8B for guix-patches@gnu.org; Sat, 08 Jan 2022 02:01:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n65io-0006Nf-6s for guix-patches@gnu.org; Sat, 08 Jan 2022 02:01:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#51838] [PATCH v8 03/41] guix: node-build-system: Add JSON utilities. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 08 Jan 2022 07:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51838 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Philip McGrath Cc: 51838@debbugs.gnu.org, Timothy Sample , Pierre Langlois , Jelle Licht , Leo Famulari Received: via spool by 51838-submit@debbugs.gnu.org id=B51838.164162524224490 (code B ref 51838); Sat, 08 Jan 2022 07:01:02 +0000 Received: (at 51838) by debbugs.gnu.org; 8 Jan 2022 07:00:42 +0000 Received: from localhost ([127.0.0.1]:46245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n65iU-0006Mw-BT for submit@debbugs.gnu.org; Sat, 08 Jan 2022 02:00:42 -0500 Received: from mail-wr1-f68.google.com ([209.85.221.68]:33294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n65iS-0006Mg-NH for 51838@debbugs.gnu.org; Sat, 08 Jan 2022 02:00:41 -0500 Received: by mail-wr1-f68.google.com with SMTP id r9so13570774wrg.0 for <51838@debbugs.gnu.org>; Fri, 07 Jan 2022 23:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=NUB4vtRoQZ3Eg28+jHoOvoKcRtfvXv/CQhcYvJLd+zY=; b=ToG9qTwmSkeCh2CfBLvU9M9Ae1NzhnLK7YRk/zPPEZa8X7tqV+GK5TWUklqKHieOri LfeRYCEkTixdAWMer12VBRS4VCXdkjVL2Ftii3EzdJtNExgfMrCpehfB2DMKVsKYakeq CgZ528SI7w+DboS0GUXMvds74lsC6Z/a1jO3Tzp0Rb9XMAg07kWBrFBiHDf5k30F7GPB nYjYpR53VUFvL/24IjvJoomVmP9wdlTo2dU6QiOzF+7DiLJjUZly2rvYygTKSKSrYTKa khiigYHw0A5iPvaOSoAY9I5rGeN51m5QglwyqoqDm8qj/S/OdFNZkylz6w6DHSozp//O sIgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=NUB4vtRoQZ3Eg28+jHoOvoKcRtfvXv/CQhcYvJLd+zY=; b=61cY3Gn06KPcGcpGjfA6wovhKuhkjdME1OSiKTRLBN54EyFV8XXDGxiGfu29LzbL7I U5A1itXoeM5l/thIqBvTVdOj7qDqH4wExuM+335bEvmOI+mgcRlA+g1uppGf4pLIVfK4 pfgaeE+nC6Ek3PFPXYaRDwBbc2Nyc7+4GEdhUTTPYdu1aiPtXvCBCFT1zqEC2Ehzrs+S tekSM7oCItr0RDVTme0up+WfDkVZsSWeLsFcuAJz2Q/vJ/JDmWsX2zn6wM73ZD1zRyKH m2Xp35LWYVWhQqwmc+oMpjD9gednAQfWpi4ztkMDJNGqWzNLABBeFWC2B3dpq8PJjdoX ig9w== X-Gm-Message-State: AOAM532NLC//OE2HcUHkh8Hpu0vZPWGcqc2iedGL3juNMqSgVHJq8LLF rtabyfX1smKSt/WjrAAlJ5Q= X-Google-Smtp-Source: ABdhPJxhVlnIEnYCJcSCtSv2WzqHlrU+L1eWnhkvhJ+tL3GtIFuBSmRUInIHcvdTxorUFgXXQwAshQ== X-Received: by 2002:a5d:64eb:: with SMTP id g11mr26578177wri.135.1641625234463; Fri, 07 Jan 2022 23:00:34 -0800 (PST) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id k14sm798319wrn.59.2022.01.07.23.00.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Jan 2022 23:00:34 -0800 (PST) Message-ID: <5c5d0aa3b3a1a2054d11162af55a9175d115d4ba.camel@gmail.com> From: Liliana Marie Prikler Date: Sat, 08 Jan 2022 08:00:32 +0100 In-Reply-To: References: <71ee87241c6c8a2a49c7cff916b7e1e9d508e020.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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=1641628707; 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: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=NUB4vtRoQZ3Eg28+jHoOvoKcRtfvXv/CQhcYvJLd+zY=; b=XT25qMKVs5BchG/hr2doD4U2QsoWB9NHFm1qgsa/WQuCGjleiTSw0hrkcpL9y9bRxfIBbj hLkY2LIJ36rE9i5Gh7sO/+4E504XW+4McNt9ZJmEVlO8oYRH8nRI4155PAxSBn63RTF234 Bwdi0qNlgAdgCCe8Svv3cOEKNPN/CNZ9/VDRWKXyCo3gdwsOErQ2ebv9p3d/9zDM84W6l/ Yz6NQwpjS4etrLb9KI8ax5dUoqcKTfTOnpDRfW+V66eyLrpK0H5nyXNF7pPzfMJRxy7YjG +a4KPChtu7VGO+ejnz971lmfS6OPgc5STalRupkFg1FYRW8dWkW87tVH/FsyWA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641628707; a=rsa-sha256; cv=none; b=ZPwj1+JA3Tclyh3QQzFC3X5Aj7oF1hBH4e0UAJ52Lzxu8GZTNLxuQ4s9QMW6uW2QrWko8w q9ngrEMZQBkmU/8DaqbzgN2Br+yAm1mM4jhvhV374Lft9QwaYKjpklL4tdu+x03AcVzEfJ uD6z/+DGCAV0dlX8f/WjB9mm2tEIzgwF5jSogmdDL6uBg5t2MVM2uoSorpi6vx3i9AZ8XH 01NW9rGy8E9vxGwYsWq4zhpaCdd+xijPQkzfaoNCIELFNtxoXXDM47Cga9CSE25BRaXu5H eSxLO/GNwJuDVomgiqhRPbmUkpLWzFgLwd27hJFuwdCbd/B1Vx4/dZe6YigyTQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=ToG9qTwm; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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.00 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=ToG9qTwm; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: 0499E34122 X-Spam-Score: -2.00 X-Migadu-Scanner: scn1.migadu.com X-TUID: JthnSOlsFQLb Hi, Am Freitag, dem 07.01.2022 um 23:13 -0500 schrieb Philip McGrath: > FWIW, while I don't feel strongly about `let` vs. `define` in > general, I find SRFI-71's overloaded `let` less clear than internal > definitions and `define-values`, which are supported by core Guile. Internal definitions are an implicit letrec, which might be useful to have, but I prefer explicit let-binding. It has the added benefit of being shorter to write and having clearer scope. > I would prefer (KEY [DEFAULT] PROC). In my experience, DEFAULT is > often something simple like #f, and writing it after a multi-line > lambda expression is not very pleasant.  The reason to have DEFAULT be an optional final argument is imo symmetry with how you'd call the underlying alist functions. It makes the code a little easier to grok, but you're right that inline DEFAULT looks nicer. > The docstring no longer specifies left-to-right evaluation or that > the default DEFAULT is #f. That's a bug. > (And I still think '(@) is a better default DEFAULT.) I don't think so. Values could be of any type, not necessarily object type (e.g. suppose you're updating a key:string mapping). So explicit '(@) is preferred in my opinion. > I don't especially like all of the explicit quasiquotation of lists > in the rest argument. Two things: First it makes it easier to understand where each update begins and where each update ends. Second, I'm not satisfied with quasi-quote either (I'd like to have substitute-json* syntax ideally), but it's a fair middle ground between my ideal solution and what I could do on top of your submission in a short time. > > +(define (jsobject-union combine seed . objects) > > +  "Merge OBJECTS into SEED by applying (COMBINE KEY VAL0 VAL), > > where VAL0 > > +is the value found in the (possibly updated) SEED and VAL is the > > new value > > +found in one of the OBJECTS." > > +  (match seed > > +    (('@ . aseed) > > +     (match objects > > +       (() seed) > > +       ((('@ . alists) ...) > > +        (cons > > +         '@ > > +         (fold (lambda (alist aseed) > > +                 (if (null? aseed) alist > > +                     (fold > > +                      (match-lambda* > > +                        (((k . v) aseed) > > +                         (let ((pair tail (alist-pop alist k))) > > +                           (match pair > > +                             (#f (acons k v aseed)) > > +                             ((_ . v0) (acons k (combine k v0 v) > > aseed)))))) > > +                      aseed > > +                      alist))) > > +               aseed > > +               alists))))))) > > + > > +;; Possibly useful helper functions: > > +;; (define (newest key val0 val) val) > > +;; (define (unkeyed->keyed proc) (lambda (_key val0 val) (proc > > val0 val))) > > I much prefer a keyword argument #:combine, and I still think the > key-agnostic case is so much more common that the separation of > #:combine/key is useful. I think we could define an (alist-flatten alist #:key combine default- combine), where again combine is your combine/key and default-combine is your combine. Then we could define (json-object-union objs ...) as (alist-flatten (append-map json-object->alist objs) #:combine ...). Explicit conversion of json-object to alist and back seems to be the wiser option to me than defining everything twice. WDYT?