From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 05:05:42 2023 Received: (at submit) by debbugs.gnu.org; 11 Mar 2023 10:05:42 +0000 Received: from localhost ([127.0.0.1]:56608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paw6f-0000CS-NG for submit@debbugs.gnu.org; Sat, 11 Mar 2023 05:05:42 -0500 Received: from lists.gnu.org ([209.51.188.17]:58740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1paw6d-0000CJ-MW for submit@debbugs.gnu.org; Sat, 11 Mar 2023 05:05:40 -0500 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 1paw6b-0003tB-R2 for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 05:05:37 -0500 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1paw6Z-0001fr-VB for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2023 05:05:37 -0500 Received: by mail-ed1-x52c.google.com with SMTP id y4so868720edo.2 for ; Sat, 11 Mar 2023 02:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678529134; h=mime-version:user-agent:message-id:date:subject:to:from:from:to:cc :subject:date:message-id:reply-to; bh=9PoJyd0Mxfoj6OiWC8acTOmlQTM1+1IEXQ2nCp6RnnA=; b=fyUViBYl1OuTNKnm+rEUS6Mu8Jn/aIimsWGfaFbXOj9gPNJOCy7kbl0EWjmNyvTI5g WTECO39Zt2fTFB82jlEcxF3IuI2dwIl+l7TY5ZSGgwh8btCIZlSPMYDO0iH5nKWRZh6b /e+gRfBlKtmx4/nsW3QCsOZhKr0wMAYdqlNvy+YjXGhDtG9RzQagpx1bGsrixYIK1p+Y h6bz+J39PzznTCcjoQ57jGBjjMu4kTmVO+vBYTYbqjYoxfNLCzbSAk/wnWlpPEtIdojV sveoeUX4m3curOOUkff/kiAY17RcHIXV0tk5Exwgb7+xV/2sEckVA/HZ0Dct+sOk7Zv5 TYYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678529134; h=mime-version:user-agent:message-id:date:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9PoJyd0Mxfoj6OiWC8acTOmlQTM1+1IEXQ2nCp6RnnA=; b=ejC5o0U5724cLtm6BNC6W2MoVrcSfxu7ht6impTWovaRwgFVy53jYK4D0gUhK89hWA YUg+YLG9ZUJXAcuK8asntReUZ5/VjCxaGVdSJn30Pz8BHmwVeHvbgoy/jfUocyU/mdyd vAnchkC86xuAdSRufDazx632XMOTUXUZh6c3CXoHp19YHArGT4sURXdNZOfM43uq0e0i rmkAeJOPKoV4ERvs5ppXU3tqe5+VJRENI3jYJXHC84Ih+C2F0qKOBLwHFZ/yj55omfhJ ayz6L0zcqs2J6nLhhvwF0dN0aXRs/pSTdm88dBrfzUXwqyHWEX1SQdXDAJl9ku2/9svB NxPA== X-Gm-Message-State: AO0yUKVVYM07nl9dD+7/JiCnuBDJIEM0wxsvLuNwi8TokX2uyICpP0m3 kgZWRXccVa4oXlTvuNDJVDrQDy27MFqKcQ== X-Google-Smtp-Source: AK7set9P+bBjQsqGaTkwOljBxmVnNufGHBd3hPdtzfFbuegIKiAzWKD7JioBdPuBzfq9GjkwWAGYAQ== X-Received: by 2002:a17:906:a1cc:b0:878:7189:a457 with SMTP id bx12-20020a170906a1cc00b008787189a457mr29260788ejb.51.1678529133931; Sat, 11 Mar 2023 02:05:33 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::8b3a]) by smtp.gmail.com with ESMTPSA id t21-20020a50ab55000000b004e0334ee807sm980388edc.40.2023.03.11.02.05.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Mar 2023 02:05:33 -0800 (PST) From: Augusto Stoffel To: bug-gnu-emacs@gnu.org Subject: 29.0.60; Add map-insert!, eventually get rid of map-not-inplace error X-Debbugs-Cc: Michael Heerdegen , Nicolas Petton Date: Sat, 11 Mar 2023 11:05:32 +0100 Message-ID: <87fsabr4b7.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::52c; envelope-from=arstoffel@gmail.com; helo=mail-ed1-x52c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) In my understanding, map.el should operate on values, like a functional language, an not on objects (a.k.a. identities or places) like procedural scripting languages. This confusion is what originates the map-not-inplace error, which should not exist at all, for the same reason that nconc, nreverse et al. don't have this problem. Also, this is not to say that map.el should not provide GV getters and setters; it should. But its functions should operate on values, even the destructive ones. So I suggest adding the following: --8<---------------cut here---------------start------------->8--- (cl-defgeneric map-insert! (map key value) "Return a new map like MAP except that it associates KEY with VALUE. This may destructively modify MAP to produce the new map." (map-insert map key value)) (cl-defmethod map-insert! ((map list) key value) (if (map--plist-p map) (if-let ((tail (memq key map))) (prog1 map (setf (cadr tail) value)) `(,key ,value ,@map)) (if-let ((pair (assoc key map))) (prog1 map (setf (cdr pair) value)) `((,key . ,value) ,@map)))) (cl-defmethod map-insert! ((map hash-table) key value) (puthash key value map)) --8<---------------cut here---------------end--------------->8--- This gives: (map-insert! nil 'a 1) => ((a . 1)) (map-insert! '((b . 2)) 'a 1) => ((a . 1) (b . 2)) While one the other hand: (map-put! nil 'a 1) => Debugger entered--Lisp error: (map-not-inplace nil) (map-put! '((b . 2)) 'a 1) => Debugger entered--Lisp error: (map-not-inplace ((b . 2))) I would then suggest to make map-put! obsolete, due to its limitation and conceptual confusion. Also, the docstring could be clarified like this: --8<---------------cut here---------------start------------->8--- (cl-defgeneric map-put! (obj key value &optional testfn) "Associate KEY with VALUE in the map OBJ. If KEY is already present in OBJ, replace the associated value with VALUE. This operates by modifying OBJ in place. OBJ must be an object that can be modified in place; otherwise signal a `map-not-inplace' error." ;; `testfn' only exists for backward compatibility with `map-put'! (declare (advertised-calling-convention (map key value) "27.1"))) --8<---------------cut here---------------end--------------->8--- As to the naming of map-insert!, we should first decide if the exclamation mark is the convention we want for destructive operations. One issue here is that map-delete is destructive. In fact, there should be a destructive and a non-destructive version of that method too. In theory no program should break if we changed map-delete to be non-destructive (it currently can be so, but as usual there's no promise of that). As to my other recent tickets on map.el, I'm willing to provide the patches once it's agreed what exactly should be done. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 14 23:31:36 2023 Received: (at 62119) by debbugs.gnu.org; 15 Mar 2023 03:31:36 +0000 Received: from localhost ([127.0.0.1]:38891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcHrU-0006DA-9z for submit@debbugs.gnu.org; Tue, 14 Mar 2023 23:31:36 -0400 Received: from mout.web.de ([212.227.17.11]:36339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcHrS-0006Cw-5a for 62119@debbugs.gnu.org; Tue, 14 Mar 2023 23:31:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1678851085; i=michael_heerdegen@web.de; bh=KO0pbs0rv9/NxWxGiueKLi+k8e4tj0NxsXiDXbbQa+A=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=FtkLCFNdba7mBIOafy3jY89gaxaorQHGcdQg54AjPo81TfFrD2eNXDBqxqesd2I/a ZTBBliXfZg2JwsYj4BnSaR4ddfYzWQjhEAeLHyBf3e5T2EnM76Hf0HzWn6w8UvyhCb mnnJDS8z1vg8bNakJefT5VXkwg1hB1li/i5XTCw7RpkJ1yB1HU3k2gyKIyUtl+/TZM jzwOwxs0jZj+1zG3WVn1/IzNsO5Fd0O+H5OniF4HqZGRKmZyCnDzh2dzRpn2TWMkCe OQu0NosAYkld5iqiT2dN+tK1/B7tqDtnEaTDOmRQc1XJeMtFB1DWzvPfX6IdywMqc8 CKb3wM3yVTIHQ== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([178.14.74.146]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1M608n-1paL7X3nh5-007cWs; Wed, 15 Mar 2023 04:31:24 +0100 From: Michael Heerdegen To: Augusto Stoffel Subject: Re: bug#62119: 29.0.60; Add map-insert!, eventually get rid of map-not-inplace error In-Reply-To: <87fsabr4b7.fsf@gmail.com> (Augusto Stoffel's message of "Sat, 11 Mar 2023 11:05:32 +0100") References: <87fsabr4b7.fsf@gmail.com> Date: Wed, 15 Mar 2023 04:31:23 +0100 Message-ID: <87y1nyn110.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:19y9xacQ0P0sRxqJ90qdc977jTExNrzEBPdNwmMGrCXckgmW7yN nv6rIU5Gcj6NeiVdkmNMJn9y+KuZyE64nO6/bbTyGmI9exewvfvBFnO8JH6yXNB72uk6Pu2 Bsce6YzRmVvW0jhLPSDAFG3dGhF+qsY2o8ruZjNkvyf93BzsEglfZR/uJyCqEqjw897UvaG 7BzRHEbuzAv9+DG+hpUOA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:mS1iFKdISRg=;M3tzj/HiMbBFdzkqglxJcbVALXS bCcFjzSJ0RPJG+Rk3KMF9JYl4VVB40brJhmvRLIUIjrrqpp1jcJydFx43no6mST7VDAfuDuMB DPYf/3K0vuQucOJdOGssBLJBMxAJbyD3ELM8oMOqTv6PukV5KbDThQBY2oXtoIhGY4BWCMfuW qX2fdCFqyOKPyT3UG+gUxiOfWS3/+DPYe8A+2ORAoRVOsVLPqlFqXO08CwYBElN2Q4KWRukxA 4h+OOgueGVqgKpe/P1Ln+eTpVpr6Of4EXql7sqxsQ8d5vmtqRPVtfQLygVR3cPg2D6IayjiN7 AEHXWP7VdFmyImKobpZJHdP8Z/F5g/uSNMzgLmyceGzAM0TCmRPW2ZKt2EBAdMJZf9IQ5+dEa 1hlLQpfzjueWVgCB78f6FV38qN6pUNcF830C6pOJoZVGw8E1ATBUD5NF+1ECCcnmgDAnsuQlK 06/gAu1LPGWrJG957WJwWCEnvgL9ATPxQcAkCQGBR3IGEddegDWIni6y7Mry2cmIq6r4UPnsr eTvgMP9Yyz5CCsaY4S9wh7HR1EkRxKEL54RN4BdL9DY3dNgcOLdoKFNdbtEl2YFQU77glc/gu e9jpSo1WE/EHS4b5ConSN+S54jcd23RNavtniNw3WNkHCSo0jVWaKDQNJDRCm6f2Al1GNY6I7 iHXmmniysZKY1A6gVmcn1+S5v2XeUOjaTjc8SiDSioghKGzPipp5bDrltj+Bv6Wj7QL+TLHIx /ZF+8r0866Dg3i1Ewhzwq1P5+L8rHQ8lvrAfOH1IUHThJ9OAuufD6g/8ljL/S+iQjH94uYhen CJVzTaqyRwNUnJmjzpfYp59RwfpvDupUyyyupmiDw5CQOdroEhtHgxtpZNzQ0LUXJyspjX0ym syQH9d6uuwRKY28/l9e7fMzfwB9euoaYcpz7JIHZpNd6peHduQXOfe9DOZERdaPchVmLnR4Jw m335oA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62119 Cc: 62119@debbugs.gnu.org, Nicolas Petton X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Augusto Stoffel writes: > In my understanding, map.el should operate on values, like a > functional language, an not on objects (a.k.a. identities or places) > like procedural scripting languages. I guess some people will disagree that we should make that a core assumption in this library. > So I suggest adding the following: > > (cl-defgeneric map-insert! (map key value) > "Return a new map like MAP except that it associates KEY with VALUE. > This may destructively modify MAP to produce the new map." > (map-insert map key value)) > > (cl-defmethod map-insert! ((map list) key value) > (if (map--plist-p map) > (if-let ((tail (memq key map))) > (prog1 map > (setf (cadr tail) value)) > `(,key ,value ,@map)) > (if-let ((pair (assoc key map))) > (prog1 map > (setf (cdr pair) value)) > `((,key . ,value) ,@map)))) > > (cl-defmethod map-insert! ((map hash-table) key value) > (puthash key value map)) But I like this idea. > I would then suggest to make map-put! obsolete, due to its limitation > and conceptual confusion. Also, the docstring could be clarified like > this: > > (cl-defgeneric map-put! (obj key value &optional testfn) > "Associate KEY with VALUE in the map OBJ. > If KEY is already present in OBJ, replace the associated value > with VALUE. > This operates by modifying OBJ in place. OBJ must be an object that > can be modified in place; otherwise signal a `map-not-inplace' error." > ;; `testfn' only exists for backward compatibility with `map-put'! > (declare (advertised-calling-convention (map key value) "27.1"))) I don't like renaming the first argument to OBJ (you forgot to change the calling convention btw). Using a sensible name for the first argument is important. Apart from that I found the original version of the docstring not worse or less clear than yours. > As to the naming of map-insert!, we should first decide if the > exclamation mark is the convention we want for destructive operations. Personally I would rather expect that a *!-named function modifies something in some location and the return value is not the important part. > One issue here is that map-delete is destructive. In fact, there should > be a destructive and a non-destructive version of that method too. I like your `map-insert!', and this will also have advantages. I'm not sure we want to give up the old generics (like `map-put!') however. I'm also not sure if it would be worth it to have both at the same time, since the cost is that we need to have separate implementations for all generics. I how others think about this suggestions. Thanks, Michael.