From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Interpret #r"..." as a raw string Date: Sun, 07 Mar 2021 01:13:04 -0500 Message-ID: References: <20210227.031857.1351840144740816188.conao3@gmail.com> <83pn0mppjd.fsf@gnu.org> <87zgzqz6mu.fsf@db48x.net> <83h7ls67rv.fsf@gnu.org> <83y2f2xc4n.fsf@gnu.org> <87v9a4n7g9.fsf@mdeb> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7640"; mail-complaints-to="usenet@ciao.gmane.io" Cc: db48x@db48x.net, eliz@gnu.org, conao3@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Matt Armstrong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 07 07:14:50 2021 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 1lImgk-0001rd-Fp for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Mar 2021 07:14:50 +0100 Original-Received: from localhost ([::1]:49944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lImgj-0002bR-HV for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Mar 2021 01:14:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lImfA-0001nC-Ig for emacs-devel@gnu.org; Sun, 07 Mar 2021 01:13:12 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53636) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lImf8-00057V-Ij; Sun, 07 Mar 2021 01:13:12 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1lImf2-0000rR-D4; Sun, 07 Mar 2021 01:13:05 -0500 In-Reply-To: <87v9a4n7g9.fsf@mdeb> (message from Matt Armstrong on Fri, 05 Mar 2021 22:04:54 -0800) 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:266109 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The place Eli was referring to, I believe, is this from (info > "(elisp)Equality Predicates"): > The Emacs Lisp byte compiler may collapse identical literal > objects, such as literal strings, into references to the same > object, with the effect that the byte-compiled code will compare > such objects as ‘eq’, while the interpreted version of the same > code will not. Therefore, your code should never rely on objects > with the same literal contents being either ‘eq’ or not ‘eq’, it > should instead use functions that compare object contents such as > ‘equal’, described below. Similarly, your code should not modify > literal objects (e.g., put text properties on literal strings), > since doing that might affect other literal objects of the same > contents, if the byte compiler collapses them. Here's how I would write it. It does not use "literal". It does use "constant", meaning that the object appears directly in the expressions and will be used at run time. A constant does not have to be written in the source. It could be generated by a macro. I've assumed that this applies to quoted lists, too, but I don't know for sure -- is it so? I've made several other improvements in the punctuation and usage. I suggest installing those changes too. ====================================================================== The Emacs Lisp byte compiler may unify identical constant objects, including strings (which evaluate to themselves), and quoted objects, including lists, into references to one single object. This has the effect that in the byte-compiled code the objects that were unified are ‘eq’, while when interpreting the same code they are not. Therefore, your code should never rely on objects that are equal in contents to be either ‘eq’ or not ‘eq’; it should instead compare them using functions that compare object contents, such as ‘equal’, described below. Similarly, your code should not modify an object that appears in the code---for instance, it should not put text properties on strings---since such alteration might affect other objects that have been unified with it. ====================================================================== -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)