From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Newsgroups: gmane.emacs.bugs Subject: bug#43557: 28.0.50; Please document which objects are mutable and which are not Date: Mon, 5 Jul 2021 20:55:05 +0200 Message-ID: References: <87mu0nv6y6.fsf@gnus.org> <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> <6F14B065-611C-4ACE-BBD5-50B34512C00B@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25321"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 43557@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 05 20:56:21 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0TlV-0006LB-J3 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 05 Jul 2021 20:56:21 +0200 Original-Received: from localhost ([::1]:48252 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m0TlU-0003Tj-Jj for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 05 Jul 2021 14:56:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53012) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0TlD-0003Si-A9 for bug-gnu-emacs@gnu.org; Mon, 05 Jul 2021 14:56:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35112) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m0TlB-0005BG-Tf for bug-gnu-emacs@gnu.org; Mon, 05 Jul 2021 14:56:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m0TlB-0003L9-M7 for bug-gnu-emacs@gnu.org; Mon, 05 Jul 2021 14:56:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Jul 2021 18:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43557 X-GNU-PR-Package: emacs Original-Received: via spool by 43557-submit@debbugs.gnu.org id=B43557.162551131512789 (code B ref 43557); Mon, 05 Jul 2021 18:56:01 +0000 Original-Received: (at 43557) by debbugs.gnu.org; 5 Jul 2021 18:55:15 +0000 Original-Received: from localhost ([127.0.0.1]:46658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0TkQ-0003KD-NM for submit@debbugs.gnu.org; Mon, 05 Jul 2021 14:55:15 -0400 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:40836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0TkO-0003Jv-N0 for 43557@debbugs.gnu.org; Mon, 05 Jul 2021 14:55:13 -0400 Original-Received: by mail-wr1-f52.google.com with SMTP id l5so6431937wrv.7 for <43557@debbugs.gnu.org>; Mon, 05 Jul 2021 11:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uyx6vHQmXAag8dSu1LufL7WQy69euPzRs6SclYJq5Xg=; b=rGWDsZ16T0dCwUzmRGYYpUpI3lFYXmDk+5ak8tYVEJo5iQCaqxI4zjiKdHHbrmBGBs mLfjs2qsmqdMJkWEKEM+/eE/jXyT5CVrFDlLsVmoFF5cDp66y7ddBaUl6sZiViAbTjrz OjabwOleg7lJyJecGPlv5R953DuczfYkznmZFVtXhXnZBCaNi/8lPltz/Q/Jo1mtnFPo 5+A9YDkwQJSfVXp26n6pCmP6Awb+ZRPtIgSH2Ul913//6RqDDb9+jvoaddQAzFMYg2oi xwJAOZESFqAGBtweGIAHEgPP0gHEDOhSpzkYBfIeUtP20aJCAZekelDgly5dkkBBq67h Qjzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uyx6vHQmXAag8dSu1LufL7WQy69euPzRs6SclYJq5Xg=; b=Il2BphXkwBbJf2gLVX+yNPYSE0TaqOKgBZLJR8I0MCSxW/itGWHpsDTviNrU/gBFLe FLy1j3lEeIwt0h1cuktEp5o+iG/xCoUmxDRvwIPwCx8Vrc6cZ1my4QLVP/YnwB5h41MR 6fSYd6ksxEEZlaB/PCPFUq4GAcZpu/buIzjUVXJCn+5VcMioSh/tajmBnT9p6UDc2eAc kwVtY85bpFczdOyMijoMvDQQfiRT5JMzh4r0bf/W5fWBpa83Bu4Z5QcQ9XaZMuFlA9rC CDjuhnACMiopF9/1go7VAWLnQUJTn9NlqRL6iXDWBv1Y0ImzMB/EHdRBQdpHuDUHOJN3 KLRw== X-Gm-Message-State: AOAM530mBkmcmsPP5JBTaaAS3Icnb16Typ7gzwdvTrIUzVHNK+iSMEBM ApheQlRckBlECXrkTu+wRTw= X-Google-Smtp-Source: ABdhPJzVN8M85h5XFEPawKeppNBasbiuozu8x4/hEsvnWCF+PEr53n1hZoeMf3XlOuWf+BBmhYfHqw== X-Received: by 2002:a05:6000:1acb:: with SMTP id i11mr16987241wry.120.1625511306693; Mon, 05 Jul 2021 11:55:06 -0700 (PDT) Original-Received: from smtpclient.apple ([46.128.198.100]) by smtp.gmail.com with ESMTPSA id k5sm14377528wmk.11.2021.07.05.11.55.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jul 2021 11:55:06 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3654.100.0.2.22) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:209484 Archived-At: > Am 05.06.2021 um 17:15 schrieb Stefan Monnier = : >=20 >> Assume you have the following (nonsense) function, with unknown = implementation: >>=20 >> (defun my-cons () >> "Return a cons cell consisting of the integers 1 and 2." >> ...) >>=20 >> I. Given only that information and the manual, is the following code = valid >> (i.e. can't trigger undefined behavior in any case)? >>=20 >> (setcar (my-cons) 5) >=20 > I don't think we want to labels this as "undefined" or "invalid" > (Emacs and Emacs Lisp tries hard to avoid enforcing abstraction > boundaries, and relies instead on softer forms of discipline), I'm counting almost 100 occurrences of the words "undefined" or = "unspecified" in the reference manual, so this isn't really new = terminology. It's even used in the manual directly for this purpose: If a program attempts to change objects that should not be changed, the resulting behavior is undefined [...] The remaining weirdness here is saying "objects that should not be = changed" instead of "immutable objects". Most programming languages have some notion of "undefined" or = "unspecified", often to allow optimizations or multiple implementations. = While there are downsides to introducing such behavior, often it's a = reasonable compromise between underspecifying and overspecifying the = language. In this case, the manual already explains in a footnote that the current = behavior is undesirable and Emacs Lisp should move into a direction = where attempting to mutate immutable objects signals an error (thereby = removing the undefined behavior). > but I'd > say that using `setcar` above is risky because the user has no = guarantee > about what it may impact. I think that a word like "risky" has no place in a reference manual. = What does that even mean? What are the risks? Why introduce such vague = and confusing terminology to begin with? How would this help Emacs Lisp = programmers? >=20 > I think the rule is basically, that you should only ever use = `setc[ad]r` > on cons cells you yourself created. What does "should" mean here? What happens if users don't follow this = "recommendation"? How do they identify "cons cells you yourself = created"? Again, I think such terminology brings up more questions than it = answers. > But indeed the manual fails to > document which functions guarantee to return "fresh" new cells, which > makes it hard to know which cells "you yourself created". Then let's document that (while avoiding terms such as "you yourself = created"). >=20 >> II. Which of the following implementations of `my-cons' is correct >> (i.e. follows the rules of Emacs Lisp as described in the manual)? >=20 > All of them. Good. Then let's document that! >=20 >> =46rom what I can see there are four options: >>=20 >> 1. Unless otherwise specified, objects are mutable. Then the = `setcar' form >> is valid, and only implementation (b) is correct. >> 2. Unless otherwise specified, objects are immutable. Then the = `setcar' >> form always triggers undefined behavior, and only implementation (a) >> is correct. >> 3. Unless otherwise specified, the objects that forms return are of >> unspecified mutability (i.e. they can be mutable or immutable). Then = the >> `setcar' form is invalid because the caller of `my-cons' can't assume = that >> its return value is mutable, and all three implementations of = `my-cons' >> are correct. >> 4. Mutability of the return object must be specified in all cases. >> Then none of the implementations is correct, since none of them = specifies >> the mutability of the returned cons object. >=20 > I think we have (3). >=20 Can we find a wording that we agree on and put it into the manual?=