From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Predicate for true lists Date: Wed, 10 Apr 2019 08:01:10 -0700 (PDT) Message-ID: References: <87fu3vdjjk.fsf@tcd.ie> <87bmcqhhsf.fsf@tcd.ie> <87in6xgtpb.fsf@tcd.ie> <2af892df-26cb-60b2-4fd8-067fcb3d32e9@cs.ucla.edu> <87r2kh9uwx.fsf@tcd.ie> <83h8lcnbxb.fsf@gnu.org> <87sh4s9poo.fsf@tcd.ie> <87k1q49p0i.fsf@tcd.ie> <87efgbbq2p.fsf@tcd.ie> <87a7gz8hp2.fsf@tcd.ie> <875zrn9bum.fsf@tcd.ie> <835zrm7fow.fsf@gnu.org> <878swivtcr.fsf@gmail.com> <87r2aayln2.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="48883"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Basil L. Contovounesios" , Alex Branham Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 10 17:23:04 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hEF43-000Caa-Ue for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 17:23:04 +0200 Original-Received: from localhost ([127.0.0.1]:33198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEF42-0000Qs-Sb for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 11:23:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEEwm-0002PV-Hm for emacs-devel@gnu.org; Wed, 10 Apr 2019 11:15:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEEjP-00045E-92 for emacs-devel@gnu.org; Wed, 10 Apr 2019 11:01:45 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:37444) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hEEjJ-0003px-1L; Wed, 10 Apr 2019 11:01:37 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3AExS02128762; Wed, 10 Apr 2019 15:01:17 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-2018-07-02; bh=7xnzydA9irETpx7dKhlKHHjbBjGlDkUHu+ig9VjmkR0=; b=PoOxi+NnKrpy6E+AhhFEVaplicnP/D5mzEZf7Ngy1RCzqf2bnHFKqvgdQ7SfDPztm2X/ 1bRSeZtDgFt5C4sVGy+U55KbqVLsx2Q2+oNpkizkB3ckTAIyV9fSvn//AOKXW/VOaMpj 3iZ3qGto1u2ESYh8jclN5/MOBQa9eBRRZB9ijHAajybBaHl2hv2UvcBfjsl/0CgBnw+c jXpX9uQ+b65SFq+8BvcEdl514sHSrF5+ywlBpQH0WHfm1ojnpRLhE+vOxYr6KpyuRIYI aPUXShsZI2HRu4179wa0L2rldpN7v2WwMGZeFgq+80PVZ2WA5Opz2tzMZGW1/iAtYo5w RQ== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2rpkht3q06-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Apr 2019 15:01:14 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3AF0Uuf022684; Wed, 10 Apr 2019 15:01:14 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2rph7t8qju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Apr 2019 15:01:14 +0000 Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x3AF1BLD009088; Wed, 10 Apr 2019 15:01:12 GMT In-Reply-To: <87r2aayln2.fsf@tcd.ie> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9223 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904100106 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9223 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904100106 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.86 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235216 Archived-At: > > Isn't this in direct contradiction with (info "(elisp) Standard > > Properties") which states that side-effect-free should not be set?: > > > > =E2=80=98side-effect-free=E2=80=99 > > A non-=E2=80=98nil=E2=80=99 value indicates that the named functio= n is free of > > side-effects, for determining function safety (*note Function > > Safety::) as well as for byte compiler optimizations. Do not set > > it. >=20 > No, because the audience of (info "(elisp) Standard Properties") is the > average Elisp author, whereas the audience of (info "(elisp) Writing > Emacs Primitives") is the average contributor to Emacs core. >=20 > Currently, the side-effect-free property seems to be intended as an > internal one, since it makes some pretty strong guarantees, and is > described only in the commentary and code of byte-opt.el. This is my > interpretation of the "Do not set it" wording. >=20 > Unless someone beats me to it, I intend to try to clarify this in the > next version of my patch. Caveat: I haven't been following this thread. 1. I don't see why anyone would say that some node of the Elisp manual is intended for "the average contributor to Emacs core" and _not_ for "the average Elisp author". The Elisp manual is (should be) for all Emacs users, even users who may never write an Elisp sexp knowingly. If you want to publish "internal" guidelines that apply only for code that we distribute as part of GNU Emacs then please do so elsewhere (e.g. in some dev readme or in code comments). I don't think that should be part of the Elisp manual. 2. On the other hand, it would be helpful if the doc for `side-effect-free' said something about _why_ it tells us not to set this. Imperatives like "Do not do X", with no other info (background) do not help users understand. They can sometimes be worse than no admonition. Our doc should help users understand, not just tell us not to do this or that. Could someone please add a sentence giving some idea about why it is not good to set this? If info about this "standard symbol" property is not something that you want to disclose to users then perhaps this property should not be mentioned in the manual. IMO that would probably be a bad, not a good thing, but if it's documented, and if we say something like "Don't set it" then we owe it to users (ourselves) to say why. Just one opinion (well, two opinions by one opinioner).