From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#30241: Emacs 26.0.91: "Generalized variables" are not defined. Date: Wed, 24 Jan 2018 13:25:27 -0800 (PST) Message-ID: References: <20180124200652.GA4493@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1516829057 7471 195.159.176.226 (24 Jan 2018 21:24:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 24 Jan 2018 21:24:17 +0000 (UTC) To: Alan Mackenzie , 30241@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 24 22:24:12 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eeSWg-0001YZ-F3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jan 2018 22:24:10 +0100 Original-Received: from localhost ([::1]:47447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eeSYh-000648-0H for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jan 2018 16:26:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eeSYa-00063x-Oq for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2018 16:26:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eeSYV-0006uP-QH for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2018 16:26:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33499) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eeSYV-0006uF-Lf for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2018 16:26:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eeSYT-0004tH-PQ for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2018 16:26:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Jan 2018 21:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30241 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30241-submit@debbugs.gnu.org id=B30241.151682914818777 (code B ref 30241); Wed, 24 Jan 2018 21:26:01 +0000 Original-Received: (at 30241) by debbugs.gnu.org; 24 Jan 2018 21:25:48 +0000 Original-Received: from localhost ([127.0.0.1]:41396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eeSYF-0004sn-Je for submit@debbugs.gnu.org; Wed, 24 Jan 2018 16:25:47 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:41502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eeSYD-0004sa-9A for 30241@debbugs.gnu.org; Wed, 24 Jan 2018 16:25:45 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0OLOsed082799; Wed, 24 Jan 2018 21:25:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=pOzBbf+y0KFLECmVk61ClM8f1mqwdi+6MFIIk+EGcNo=; b=owdt8zIUejKCvsvGybQVPFpqy2yGXS1Oe6IyhW7v7xbONPgLJO2Vxe4lZGXFl6QKW5PA d52X5ozCd6uVeOytK1U67CulNLCalluqUREAsbKkInR0lwZuNFEP5H81KlNyZQVq/l1h oLFWpz8vIDn5+tR0fge42fBDkpxwY4h9hhfphO2oafHYPNpsf1+6WIHGHjJh+c98+yml Du/W+q8M88ctH5pB7aB3h28t1bhkXBjkMuqf14bFfMrZn3Thpgv25QrObJmu9uNF2nlm YoLL1l7hLfxYDb+SmbjoBjd/L3wtHFJNJYLGEPXXk6eKuWHDGaNfd0av1nhUosG0bSwl /w== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2fq21s8046-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Jan 2018 21:25:30 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w0OLPTYa020959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 24 Jan 2018 21:25:29 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w0OLPSK3015676; Wed, 24 Jan 2018 21:25:28 GMT In-Reply-To: <20180124200652.GA4493@ACM> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4639.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8784 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=883 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240280 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:142482 Archived-At: > Emacs 25.3, Emacs 26.0.91 elisp manual. >=20 > In enough places in emacs, we find terms like "generalized variable" > "place form", and "place" being used. These terms are not defined in > the Elisp manual, or any place where they are used. This is a bug. >=20 > There is a page in elisp which purports to define "generalized > variable", but rather than defining the term, it talks vaguely around > it, saying it is "one of the many places in Lisp memory where values can > be stored". Does this mean it is different from the other such places? > If so, how does it differ. WHAT IS IT???? >=20 > The elisp page then goes on to give examples of "generalized variables", > never defining the term. It gives no criterion by which the reader can > determine whether some random object is a generalized variable or not. >=20 > I want to know whether a function is a "generalized variable". After a > long time trying to find out, I still don't know. I've been trying for > over an hour to use add-function, with forms like >=20 > (add-function :before sit-for (lambda () (acm-backtrace 5))) > (add-function :before 'sit-for (....)) > (add-function :before #'sit-for (.....)) > (add-function :before (symbol-function 'sit-for) (....)) >=20 > , and got nothing but unhelpful error messages back, such as >=20 > Symbol's value as variable is void: sit-for >=20 > . The documentation of add-function is likewise vague and unhelpful. > The various inflections of "sit-for" above are at a place in the > add-function form where a "generalized variable" is needed. Is a > function a generalized variable or not? Hear, hear. This is a more general problem, for all of our Common Lisp emulation or Cl-inspired stuff. (Not that the Emacs implementation of generalized vars actually emulates what Common Lisp has for generalized vars.) When Emacs has something more or less borrowed or inspired from Common Lisp, the Emacs doc explaining it (e.g. the concepts) is sometimes somewhat paltry. In such cases, you it can help to (1) know that Emacs was inspired by Common Lisp for that construct and (2) consult the Common Lisp doc. To learn about generalized variables I think you need to consult the Common Lisp doc, which is quite clear about it: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node80.html "The concept of variables named by symbols can be generalized to any storage location that can remember one piece of data, no matter how that location is named. Examples of such storage locations are the car and cdr of a cons, elements of an array, and components of a structure." When you hear "generalized variable" just think `setf'. For Emacs, we could conceivably have many more generalized vars than we have now. We might make it possible to use `setf' for functions like these, for instance: `point', `selected-* (*=3D...), `point-min|max', `current-*', ... Not that we need that, but it could sometimes be useful. In most cases it just provides a uniform way to change something. E.g., (setf (current-local-map) my-map) instead of (use-local-map my-map). The old Emacs update functions are often simpler, but using `setf' means you don't need to know the setter/update function; you just need to know the getter/access function.