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: =?utf-8?B?UkU6IDMxMzk1NTExOiAiRG9u4oCZdCBhdHRlbXB0?= =?utf-8?B?IHRvIG1vZGlmeSBjb25zdGFudCBzdHJpbmdzIg==?= Date: Fri, 5 Jun 2020 17:23:31 -0700 (PDT) Message-ID: References: <871rmvn7ge.fsf@gmail.com> <87lfl36abx.fsf@gmail.com> <1abe5965-b48e-6dee-1516-c5c233f09d01@cs.ucla.edu> <873679lel3.fsf@gmail.com> <87d06dje3d.fsf@gmail.com> 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="5215"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Paul Eggert , Pip Cet , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 02:24:24 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 1jhMdM-0001CY-Lc for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 02:24:24 +0200 Original-Received: from localhost ([::1]:54274 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhMdL-0002Qw-Jx for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Jun 2020 20:24:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhMct-00022A-T4 for emacs-devel@gnu.org; Fri, 05 Jun 2020 20:23:55 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:54196) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhMcs-00087s-OW for emacs-devel@gnu.org; Fri, 05 Jun 2020 20:23:55 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0560Iv1R090742; Sat, 6 Jun 2020 00:23:37 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=tzPppZGEgYTnZLKGohknHE9FMdSoytGR5tRh8OCfR9U=; b=sCqjAgAzwecQIg4/Z84+JMWBWSP+5oh5+9pj85uJY/w4oOnJ/svnq4BekudrUclwU9zC y6F5KHuUQVdKq/93Av6ZQIFlnDoJ81XatOW6Lra342IP4yjFIZAk/PmKnRqNI8xG0UEe poZeWAUwncwrgAg7tTRtAoSu67iM9SrwmrnSW6isUcZJCMYLONnacv6sd9gSCDUjMTyY HY9BA9grFy7NDU6tZcTNdMF+1oFd7BmI9rcT6BAHAwP57oATfiSivlsrpHiDFC7UJt7I NYXO1QP+VBAjNO2QPdTahiBo1UrqkMcwqMF4p7A4oLRztTittr1yeed9AV9qW651exSd wA== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 31f92455kt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 06 Jun 2020 00:23:37 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0560HPQt055171; Sat, 6 Jun 2020 00:23:37 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 31g08q8fa0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 06 Jun 2020 00:23:37 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0560NYPI002899; Sat, 6 Jun 2020 00:23:34 GMT In-Reply-To: <87d06dje3d.fsf@gmail.com> 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=9643 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 suspectscore=18 bulkscore=0 adultscore=0 spamscore=0 malwarescore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060000 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9643 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 adultscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 bulkscore=0 lowpriorityscore=0 cotscore=-2147483648 phishscore=0 spamscore=0 malwarescore=0 suspectscore=18 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006060000 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/05 20:23:51 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:251923 Archived-At: > > But you can give bug#40671 a read, so see some context you might be > missing. >=20 > Thanks, that's a pretty long read. There is indeed a relation, but that > bug (the first parts) is about modifying literal objects and this > particular strangeness seems bigger than that. > > I totally agree it is undefined behaviour to change structure > of literals (quoted or self-evaluating objects), also in > Common Lisp, because compilers are probably allowed to reuse > parts of the internal structure of such objects. Yes. But Common Lisp is a general-programming language. Elisp is for use with Emacs. And it has strings that have properties, like symbols. > But that's a far cry from having two different manifestations > of `equal` such objects _be_ the same object, but only for compiled > code. Emacs doesn't behave that way for quoted lists (fortunately), so > I don't think it should behave that way for strings either. +1. > An "easy" solution would be to say: in Elisp, there > are no string literals, period, because properties. +1. Clean, flexible (dunno how "easy"). > But that's likely expensive... Do we have an idea how expensive? Lots of things are expensive. And some of them are worth it. OK, some Elisp code might make heavy, repeated use of long strings, and maybe some such uses would pay a penalty. Not sure though that the penalty would be large, or "too large". And most Elisp code won't be like that, I expect. Maybe we could have a Boolean variable (which could be made file-local or buffer-local on demand). You could turn it on in some scope or for some extent, to enable some string optimization at the cost of either an occasional gotcha or systematic error-raising when you try to modify etc. Maybe that decision would need to be made at byte-compile time, or maybe the compiled code could (at the cost of being larger) respect it. > unless some clever copy-on-write semantics operate > under the hood. But I'm talking out of my elbow, > I don't really know what's under the hood here. Nor do I, obviously. I just have a hunch that, in general, string optimization isn't worth it for most Lisp code used in Emacs - not worth the loss of being able to comfortably and generally modify string properties.