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: Fri, 4 Jun 2021 15:01:34 +0200 Message-ID: <78C74FCB-EAEF-4E9F-9C79-3A2178FA60FE@gmail.com> References: <87mu0nv6y6.fsf@gnus.org> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) 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="38741"; 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 Fri Jun 04 15:02:41 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 1lp9TF-0009sI-9o for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Jun 2021 15:02:41 +0200 Original-Received: from localhost ([::1]:41852 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lp9TE-0004t0-Ay for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Jun 2021 09:02:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56106) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp9Sc-0004Q4-TA for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 09:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34245) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lp9Sc-0001T7-34 for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 09:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lp9Sc-000190-1M for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 09:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Jun 2021 13:02: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.16228117134383 (code B ref 43557); Fri, 04 Jun 2021 13:02:01 +0000 Original-Received: (at 43557) by debbugs.gnu.org; 4 Jun 2021 13:01:53 +0000 Original-Received: from localhost ([127.0.0.1]:45791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9SN-00018Z-TW for submit@debbugs.gnu.org; Fri, 04 Jun 2021 09:01:53 -0400 Original-Received: from mail-wr1-f43.google.com ([209.85.221.43]:33457) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9SI-00018H-06 for 43557@debbugs.gnu.org; Fri, 04 Jun 2021 09:01:47 -0400 Original-Received: by mail-wr1-f43.google.com with SMTP id a20so9293918wrc.0 for <43557@debbugs.gnu.org>; Fri, 04 Jun 2021 06:01:41 -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=RQqbYxVe6KlTcO4IqM2hMTqTgtcpTdAtUpkcji9Pao0=; b=cLkvnZi0idVritj9pk9EON5P9vx8HZhPiJJVsg9Mp2oKlbdVvlDMsfCx3upFu388oZ GssRpVMTlkjviWZ47hkP8dJlf8ON6SDYaQagTEW3Uwpm9wTjDVzauy0MHSEZDNx7Rz53 cbvNJyu/AC2ScwGwNeoFzQaptKBnztFQShbvHP15G1+uk7wWxgNV+Zp5YVXzOZHUDAsL rS1f8Hs7vCXkMCKFtAxtDptlYmVGFlGhA70l/OWiVY9tLnv45WiUXr9D3VHA0Ra6opvk mLTWB94FknGaUPNq4HpIE7k1RRCzmlv08wIclUW4cSHLipAwHbIPEyo82U0nQiSPiF5D UCGw== 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=RQqbYxVe6KlTcO4IqM2hMTqTgtcpTdAtUpkcji9Pao0=; b=tFLCKOXznxn9gsfwhVtGTNIJ5WGoQD7l+euh8F2rBR/++ZjiwTa7QdWwKktRxFZqQ7 HQwTgELdaAczI8nMIrqaA2DGX4yKJkubCyV1q9hac5/erfQDAw9zIDLsgzpdSslm2f3r GGsYM1RffiQszKeq6vGP57iZu7YaZm+mIX9cSXu5YbqLIVg4BS4WuVLswxrtUlVSzfYK kW3Kqd37K9nUubVEwZxBDFYJkkO43PUYajkKWluJda3H+KhNfd/ijGoi4hGjK4RfEKHU Zp9fah7avfhJl+BujFmdhhW3K5ODmNaTwFpouWheJl2rnBJjKUBjyKjMILbfoLfaHwfK d3+A== X-Gm-Message-State: AOAM531fEGJicZBbfCd6jIKhKJfTs9hzD6gfsdmNJ+eK3MA29jPEBd2L izQV02w+/7k6O77edoWFzVw= X-Google-Smtp-Source: ABdhPJylAg/GCls5pLju6GRjrENT7jOJR6DwcwuExFGzJ1nmTQUm0htVLBii+QX9WImf01adCkiDVA== X-Received: by 2002:a5d:6b09:: with SMTP id v9mr3814387wrw.297.1622811695900; Fri, 04 Jun 2021 06:01:35 -0700 (PDT) Original-Received: from smtpclient.apple ([46.128.198.100]) by smtp.gmail.com with ESMTPSA id v16sm6074246wrr.6.2021.06.04.06.01.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jun 2021 06:01:35 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3654.80.0.2.43) 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:208011 Archived-At: > Am 03.06.2021 um 16:41 schrieb Stefan Monnier = : >=20 >> I disagree. "Pretty clear" would mean "allowing the reader to = classify >> each Lisp expression w.r.t. the mutability of its value", and as the >> section only gives a few examples, it can't do that. What it should = do >> in addition is provide rules on how to classify any given Lisp >> expression. Each possible Lisp expression has to fall into exactly = one >> of three categories: >> - The value is mutable. >> - The value is immutable. >> - It is unspecified whether the value is mutable or immutable. >=20 > While I can kinda see where you're going, it's still pretty fuzzy to = me. > I think it would be more clear if you could give concrete cases where > you'd want to use such information. I don't know how concrete a case you want here, but basically I'd like = the manual to describe the semantics of (let ((var FORM)) (setcar var VAL)) for arbitrary values of FORM (assuming that FORM returns a cons object). = Likewise for `aset', `set', and the other object-mutating primitives. What the semantics of such a form are depends crucially on the = mutability of the value returned by FORM: if FORM returns an immutable = object, then the overall form triggers undefined behavior. In other = words, the manual needs to provide a procedure to classify forms = according to the mutability of their return values. >=20 >> Then the docstring of `list' and the ELisp manual should say that. = The >> difference between shallow and deep immutability might not be clear = to >> all readers, so it's important that it's documented as well. >=20 > This is a pervasive issue, much more pervasive than `list` and that > applies to pretty much all programming languages. So I don't think it > has its place in the doc of `list`. >=20 > I hope the box diagrams of the intro to ELisp can be considered > a documentation of this phenomenon. The Lisp manual should still make this distinction explicitly. It can = be derived from the structure of lists, but it's a subtle point that = deserved reiterating. >=20 >> it must be possible for programmers to derive whether (setcar var = ...) >> is allowed from some set of rules plus the docstring of the function. >=20 > [ Aha: here's is an example! ] >=20 > Mutability says whether it is *possible*, rather than whether it's > *allowed*. Most (all?) cons cells are mutable, but it is strongly > recommended to refrain from mutating most cons cells (because it > can/will have unexpected consequences because that same cons cell is > also used elsewhere). >=20 > So what you're asking here is not exactly mutability but something > slightly different, which is not very well defined nor > documented, indeed. I don't think there's a meaningful distinction between "possible" and = "allowed" as far as code authors are concerned, and I don't think the = manual should use such vague terms. Likewise, "strongly recommended" = belongs into a style guide, not a reference manual. In the end, the = ability to write programs boils down to knowing the semantics of the = lexical entities of the programming language in question, and for that = to work the semantics need to be documented. The Info node `Mutability' isn't actually so bad in explaining these = concepts on a conceptual level. It says clearly that mutable and = immutable objects exist, and that attempting to mutate an immutable = object triggers undefined behavior. (I dislike the manual's usage of = the phrase "should not" to mean "undefined behavior", but that's a = different can of worms that we don't need to open here.) I don't want = to introduce new concepts or terminology here. What's missing is really = what this bug is asking for: a procedure to derive the mutability of = objects from the forms that produce them. The `Mutability' node = documents this for some objects, but not all.=