From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master f51f963: Fix some side-effecting uses of make-text-button Date: Sat, 06 Jun 2020 18:14:29 -0400 Message-ID: References: <20200604223056.17078.81265@vcs0.savannah.gnu.org> <20200604223058.1850020A26@vcs0.savannah.gnu.org> <87eeqtiy4x.fsf@tcd.ie> <87img51y04.fsf@gmail.com> <5c66eeb5-a513-0443-4316-e41aae118677@cs.ucla.edu> <87img4zjy7.fsf@gmail.com> <170bedfa-7119-4d6a-9d4f-e94ba0f7cc2b@default> <87pnacxbnk.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="46641"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "Basil L. Contovounesios" , Paul Eggert , Drew Adams , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 07 00:15:15 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jhh5v-000BzX-Cp for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jun 2020 00:15:15 +0200 Original-Received: from localhost ([::1]:41610 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhh5u-0007F6-Cr for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 18:15:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59308) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhh5I-0006nR-Ag for emacs-devel@gnu.org; Sat, 06 Jun 2020 18:14:36 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54910) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhh5F-000208-Jn for emacs-devel@gnu.org; Sat, 06 Jun 2020 18:14:35 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8E12144155B; Sat, 6 Jun 2020 18:14:32 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3032D44106F; Sat, 6 Jun 2020 18:14:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1591481671; bh=hqYklwJXgQ36Q7C7po/a/uWyMSqYpBrZo3X9tf6fuyE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GkYv3jQxjkeAEkPINjXwRMvP5q7LvyWKwuW7edajssgiXmUjcJ+y4w6HY735ECl7U 1e3qjXA/Rnmb1uk7qZ+Xbz/BQCq5UHtdMpOM+FkFZTYseZZ5zYf4qh3RBt87DLcWds 0VilOZCgMnY4q3Sm3IPLY+bVnNx+4vLPgr7DwKb4Rc1dDOLhezXqtXEfY5xtd3zobq t7SXGla9TmvR3d4p1O3U7TuaWtAl2UEA+lods5sfryyCan3qH3/ooiTEb6e5G3gZl4 jAcMSskFcLSQJGLp0dolRuWiokERsltDzqpzdVlNmdue5hwnftCioDRey7jt/pwn/T cB5ZmWASeVGDQ== Original-Received: from alfajor (unknown [157.52.17.179]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B1F56120B68; Sat, 6 Jun 2020 18:14:30 -0400 (EDT) In-Reply-To: <87pnacxbnk.fsf@gmail.com> (Pip Cet's message of "Sat, 06 Jun 2020 19:00:15 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/06 18:14:32 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251973 Archived-At: > I don't see how literal data is special that way. In code (let ((x "foo")) (cl-assert (eq (aref x 0) ?f)) ...) every programmer I know expects the assertion to be true, always, no matter what. Yet the assertion will fail if `...` does something like (aset x 0 ?o). That's what makes literals special. This is not unique to Lisp [ tho Lisp experiences this much more because of the presence of `quote` which makes it possible and common to have arbitrary literals embedded in the code. ] IIRC, in C the standard says that modifying a string literal has undefined behavior. > If I expect a function to look at a string argument, but it actually > modifies its argument, that's equally confusing. I hate mutability, yes. But mutability of literals amounts to self-modifying code, which is yet a bit more evil. > If I modify data that's been used in a hash key, that's even more > confusing. If I modify data in an image spec in a Lisp callback from > the image backend, Emacs will crash. These cases deserve being > thought about, too. We agree, but I'm not sure what it is you're suggesting we should do. We obviously can't make existing data types unilaterally immutable since it would break way too much code. Are you suggesting we add new constructors for "immutable cons", "immutable string", ...? Or a `set-immutable` function? > The cost of this isn't negligible; the single bit which I expect will be > kept for every string, cons cell, or vector isn't that significant, but > so far what's been proposed would be complicated to implement, explain, > and use. I'm not exactly sure what has been suggested, to be honest. Are you referring to the idea of making literal strings immutable? I'm not sure what is the implementation plan for such a thing. It seems at least not completely straightforward. > It would lead to some people developing a false sense of security and > others becoming insecure and copying everything needlessly (and > dangerously, for cyclic objects). And it would effectively prevent any > competing system of mutability, I fear. That makes me think there's been a fairly concrete proposal that has been made and which I missed (since otherwise, it seems unclear how you'd get to these conclusions). Can someone point me to it? Stefan