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.bugs Subject: bug#40671: [DOC] modify literal objects Date: Sun, 10 May 2020 21:21:16 -0700 (PDT) Message-ID: <9982fae9-cc93-439e-8fe5-a68bdb21c637@default> References: <37a54ac2-da80-ca35-9c01-38c8e12a4b5f@yandex.ru> <9375aaeb-2a9a-b307-c793-0d99328201ea@yandex.ru> <7fe0574a-62ae-94fb-2e55-1a69de6ce828@cs.ucla.edu> <91857438-f44a-90f4-dfe2-a32224ba3994@yandex.ru> <880dc34b-46a9-0149-3c6e-0a951a70125d@cs.ucla.edu> <9c46b93e-a855-0be0-7ab0-50cb8c5cd74d@yandex.ru> <48e90f87-1519-9101-d54b-4bfd81a0c936@yandex.ru> <252d6368-ddea-2f41-b53f-cd927ebc3d1d@cs.ucla.edu> <43d93102-d361-f64b-971b-909418b89fca@yandex.ru> <2ca64f28-1255-4135-6e45-0f0e12b9e72d@cs.ucla.edu> <0c7570cb-bf52-a617-bf54-27a47c54e04a@cs.ucla.edu> <04298f7d-f2c0-5186-57d3-522e3d886166@cs.ucla.edu> <88af48c6-bc39-6ab0-59ec-7d537f2d375d@yandex.ru> <41d69e2e-561f-743a-e1f0-282b2e22b66c@cs.ucla.edu> <87mu6ftk6o.fsf@web.de> <873687xjqn.fsf@web.de> 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="115800"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ke.vigouroux@laposte.net, Paul Eggert , 40671@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Dmitry Gutov , Richard Stallman To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 11 06:22:22 2020 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 1jXzxN-000U12-Ua for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 06:22:22 +0200 Original-Received: from localhost ([::1]:42942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXzxN-0005SI-0H for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 00:22:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55602) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXzx4-0005QK-KQ for bug-gnu-emacs@gnu.org; Mon, 11 May 2020 00:22:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39373) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXzx4-0000os-AX for bug-gnu-emacs@gnu.org; Mon, 11 May 2020 00:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jXzx4-0007rC-6T for bug-gnu-emacs@gnu.org; Mon, 11 May 2020 00:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 04:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40671 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 40671-submit@debbugs.gnu.org id=B40671.158917089330117 (code B ref 40671); Mon, 11 May 2020 04:22:02 +0000 Original-Received: (at 40671) by debbugs.gnu.org; 11 May 2020 04:21:33 +0000 Original-Received: from localhost ([127.0.0.1]:50910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXzwb-0007pg-FW for submit@debbugs.gnu.org; Mon, 11 May 2020 00:21:33 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:55620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXzwY-0007pN-Rs for 40671@debbugs.gnu.org; Mon, 11 May 2020 00:21:31 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04B4Dfwi052433; Mon, 11 May 2020 04:21:22 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=EhcwSjv23tqBtjhGHl+wMA87AjuGJ9PF0jVGmaeTPig=; b=UfHXXYY+KIjS4OVUc6PbOJwG2/dMbZs0iuHQdM+OySqRjza0YtTZRYjsxAOm0fBaP7JH Ij80QOwZZCJpZvnx1NqCvXOncg5rLH8WAsj1HmpfijfwHZCpDOZcffbAmZRaFxnvUBeP agiQ4FxFI2AMaZjntXAJzljZChEp7kAH0fCKs5w0SNXy+EG0Ji6aA2BKxYLBVABt51qu 6Az+rn/HIWrHJjURSUW4SEKIChiiZ1/j1dl+ZaO7GVdpk4NqrMSke0BTRsU4fjuzDw3P lSMo0uLGKkPB94anrdInuCzzqTOmOTRFlZfDeXezEzPQktTWUxgtiG7iWFzPsRJDE27E 3w== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 30x3mbjqda-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 11 May 2020 04:21:22 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04B4JTfm070230; Mon, 11 May 2020 04:21:21 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 30x63kuttq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 May 2020 04:21:21 +0000 Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 04B4LHdG014971; Mon, 11 May 2020 04:21:17 GMT In-Reply-To: <873687xjqn.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 suspectscore=18 malwarescore=0 phishscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110033 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9617 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 impostorscore=0 mlxscore=0 suspectscore=18 bulkscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005110032 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:180052 Archived-At: (This ended up long and a bit off-topic; sorry. Hope it still helps.) > > And it's especially not good to use "value" in the two > > different senses, as (1) something you see ("appears") > > in a source program and (2) a runtime value that results > > from reading, byte-compiling, or interpreting that source > > code. > > > > Maybe "object" or "Lisp object" instead of "value", for > > #2? >=20 > The term "value" is used all over the place in the manual for #2, so > people are familiar with it, we need a better term for (1) instead I > think. (info "(elisp) Equality Predicates") already uses the term > "literal object" btw: >=20 > 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 =E2=80=98eq=E2=80=99, while the interpreted version = of the same > code will not. BTW, that node does NOT already contain that text. That paragraph is new for Emacs 27, which is not yet released. IOW, that text is _proposed_ for Emacs 27. But OK. That describes the problem as being about "literal objects". That's essentially the message we're discussing, I think, but it should be broadened beyond just the byte-compiler, I think. Where, if anywhere, does the manual define or describe "literal objects"? I don't think we want to be doing that, unless it's done carefully. For the message we're talking about, I'd say start by talking about source code: forms, sexps. Yes, the sexps that are problematic are, I suppose, what that text calls "literal objects". But I don't see that term defined anywhere. And it seems odd to me to talk about source-code thingies as "objects". Maybe the result of reading, or the result of some initial stage of byte-compiling or interpreting, is a "literal object", but is a source-code sexp a "literal object"? A "literal string" makes sense to me, as a string in source code ("..."). But "literal object" doesn't sound like a source-code thing. Perhaps that's what literal numbers, strings, etc. in source code are called now - "objects"? Sounds odd to me. Checking `i literal' in the Emacs 27 manual, I see no "literal object", but I do see "literal evaluation" and "literal in rx", where "literal" is used as a noun (in both cases presumably). However, the former index entry takes you to node `Self-Evaluating Forms', which never once uses the word "literal" (as adjective or noun) - it talks only about "forms", i.e., source code. That text looks OK. The index item seems wrong - you never get any text that tells you anything about "literal evaluation". This node, and index entry "literal evaluation" are in Emacs 26 (and probably earlier). [Index entry "literal in rx" takes you to node `Rx Constructs', where you find `(literal EXPR)', which is about matching a "literal string". To me, "literal string" is clear enough, and I think of it as both a source-code thing (text) and as a Lisp object (after reading the text, for example). This node is new for Emacs 27.] Searching the Emacs 27 Elisp manual for "literal" I see that there is another occurrence of "literal object", also in a node that is new for release 27, `pcase Macro'. There too the term "literal object"is totally unexplained: "Matches if EXPL equals the literal object. This is a special case of =E2=80=98'VAL=E2=80=99, above, possible because literal objects of these types are self-quoting." (The "possible because..." is not correct English, and I don't know what it's trying to say. Maybe "possibly because..." was meant. Or maybe what was meant was to end a sentence after "above" and start a new sentence with "This is possible because...".) And again, in another new-to-Emacs-27 node, `Backquote Patterns', I see "literal object": "Matches if the corresponding element of EXPVAL is =E2=80=98equal=E2=80=99 to the specified literal object." And again, the term is totally unexplained. (That node also has "literal symbol", which, like "literal string" doesn't shock me. It is "literal object" that I find odd.) Both Emacs 27 and 26, node `Mode-Specific Indent', mention "a literal value (usually zero)". That's OK, I guess, but I think it's untrue. I think what's meant is just "a number (usually zero)". There's nothing literal about it. Node `Rx Constructs' of Emacs 27 introduces "Literals" (noun) as forms (source-code sexps), and shows that they can be strings or chars. I don't have a problem with that. Node `Rx Functions' says "if `literal' or `regexp' forms are used", and I guess that's referring to the forms `(literal...)' and `(regexp...)' introduced in node `Rx Constructs'. And it refers to "string literals". All of that's OK. Node `Extending Rx' mentions "a list literal". Again, like string literal, char literal, etc., this isn't introduced anywhere that I can see, but that's OK - use of "literal" as a noun in such cases clearly means the same as "literal string" etc. Node `Module Initialization' is another new one for Emacs 27, and another place where "literal" is used as a noun: "number literal". Again, no problem for me with that (like "string literal"). All other occurrences of "literal" in the manual are about literal chars, finding a file literally,=20 displaying or matching text literally, or replacing literal text. No problem there, and nothing new there. In sum, "literal object" is nowhere defined, described, or explained. And "object" sounds wrong, to me, when referring to source-code text.