From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: master f51f963: Fix some side-effecting uses of make-text-button Date: Sat, 6 Jun 2020 13:23:43 -0700 (PDT) Message-ID: <837642c4-4bdd-4db3-9fe5-4523df349703@default> 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> <31332591-f540-de69-26a8-03c0d8dd2c9d@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="1465"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , emacs-devel@gnu.org To: Paul Eggert , Pip Cet , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 22:26:25 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 1jhfOb-0000ET-4k for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 22:26:25 +0200 Original-Received: from localhost ([::1]:46020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhfOa-0004fM-7x for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 16:26:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhfO4-00041E-TV for emacs-devel@gnu.org; Sat, 06 Jun 2020 16:25:52 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:44316) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhfO3-0001B1-St for emacs-devel@gnu.org; Sat, 06 Jun 2020 16:25:52 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 056KOEgg189839; Sat, 6 Jun 2020 20:25:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=ebiA81c8Oh6AB1VBxxkP0W9VDLX3/qGCfuk2/0/X+Bc=; b=k5S800It6iEvDQLzBLLhy1ju7gfPkaGV+B+5fxuR472ePn31yfbkKt7rExpOl1h+3MFN 5OQwYb+wnxKCKBvPPgXDEwwJ/niFv7hSNvMN3P8YExagSQqCXxSZ9YehBK2s5F6K3AS9 W4uTnqWhTD+Ju/AF2AyVSlibtNfxhstVugvHxr32rN+Mt6N+jrWAobG32a5qGU1ZI4+/ Ml88ZIVbTki0sD0NnT3Ot+PyTfkfWCjD/akdQ0RaTeYILZQ03oLhEgrQif5MFPnyG6XW H2Bfy2+qL+PIdUw8O02frNY+LMSq/bVEcZys+0X14jFQ425u6pzqpf6+wCmtMbor0j/Z xg== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 31g33ksspu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 06 Jun 2020 20:25:49 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 056KICdj053393; Sat, 6 Jun 2020 20:23:48 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 31g2y2v607-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 06 Jun 2020 20:23:48 +0000 Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 056KNlbD015665; Sat, 6 Jun 2020 20:23:47 GMT In-Reply-To: <31332591-f540-de69-26a8-03c0d8dd2c9d@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5005.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9644 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060162 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9644 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 spamscore=0 cotscore=-2147483648 malwarescore=0 phishscore=0 mlxscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060163 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/06 14:16:14 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, 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:251970 Archived-At: > > consider quasi-quoted literals: would those be immutable? >=20 > A string literal should not be modified, regardless > of whether it's quasiquoted. You keep repeating the mantra that a string literal should not be modified, with no good supporting argument. Elisp strings, and hence its string "literals" are not your textbook strings and string literals. The latter are not mutable objects, with text properties. Emacs strings are, in general. And more of them could be - they could even all be, I expect. > "False sense" because programmers would start relying > on Emacs to catch trivial mistakes involving modifying > string literals? Horrors! (Programmers should let > those mistakes persist into hard-to-debug complex > programs, as this will give them much more of a challenge > when debugging. :-) With that logic, we should outlaw list modification. Some users will make mistakes, or get confused, and get into trouble. Heck, why not take it even further: outlaw dynamic state altogether - complex, difficult to reason about, difficult to analyze and optimize by program, difficult to optimize and parallelize. Just a lot of trouble and headache, right? All such arguments are 100% valid. And there are languages based on them. Lisp isn't one of them. And by design Emacs isn't based on one of them. FWIW, I love purely declarative, applicative, logic and functional languages. Always have. I love formal logic, algebraic specification of ADTs, theorem proving, etc. But I also appreciate the dynamic, side-effecting "messiness" of dirty old bit-fiddling Lisp - and _especially_ for a user-programmer editor/env such as that dirty old man, Emacs.