From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: Predicate for true lists Date: Wed, 10 Apr 2019 16:45:00 +0100 Message-ID: <87lg0hyidf.fsf@tcd.ie> 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="150722"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , Alex Branham , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 10 17:45:19 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 1hEFPX-000d3f-K3 for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 17:45:15 +0200 Original-Received: from localhost ([127.0.0.1]:33597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEFPW-0001pH-I0 for ged-emacs-devel@m.gmane.org; Wed, 10 Apr 2019 11:45:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEFPN-0001o0-HD for emacs-devel@gnu.org; Wed, 10 Apr 2019 11:45:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEFPM-0006x7-CV for emacs-devel@gnu.org; Wed, 10 Apr 2019 11:45:05 -0400 Original-Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:39277) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hEFPL-0006wU-TL for emacs-devel@gnu.org; Wed, 10 Apr 2019 11:45:04 -0400 Original-Received: by mail-ed1-x529.google.com with SMTP id k45so2470052edb.6 for ; Wed, 10 Apr 2019 08:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=VP+zshRG+A2vd9LfpYPYvtWBvIBqv1XWfmCf6cxaTxU=; b=FhZzP6EdKe44797cFKQea0Epuks4vIL7U9qD4UHquV803EYJWuRPGBUJoc7Y/qdpFn V0SMivAJxlMsSSQwgf3Hdxb5Eg9qIgkv0LcnQpsQNP5xcxUi06FeGBaXkUsUEcPoHaRE OzlniFaV1u8n6FWQGGUmOK1U8tMXh+zDFV90qf966IWcWxkV6LWlmDK8eWSwpfKfyYgj O0L/qsE9+5aphLnVcYCZW9Mr136GiWv2+mmi2QIqXBYnvBf2QGAfpC+kvychNVpmqblC 6wXH7cHywkGfy1R1dz0yroArKzZvRaiHRfwn6ZGsk/5g6z3uMh+uZjqv8dgB7x+SLTMY 2VnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=VP+zshRG+A2vd9LfpYPYvtWBvIBqv1XWfmCf6cxaTxU=; b=PuAM0ZCg5DomTpE3TRl7TPWOhIYc0PbkS8F5MXvzbRDvF/7ZGnc++7GCn3OKGmEXHO A8yAaPcUk+UhkbBqdI6ObhF6u0YpKkXMCKQ/ZnbnmIleUDR06tnt2UXOd0/TBRVlj69E 9OhNEbldAnvr6hIKxng3heY6Bnqdy2Hh+RG+f43pdDS25LswszEPuAAplphBEsZNg3Kq BLbNc/CcXvbwrf/nTCyu23UCMQLwLScjxbVt8PkUeNCe2aTtViOvFZZQWOuzXBjKag6Q r4+AqC+uIHOk1O9tzN9PClndl/OQ7bR7AiAe7UTiULl24JbG7LQPB6bbsCPligzXcXdz TQwA== X-Gm-Message-State: APjAAAUn/sscfSlxTw3QMunBK6wmAcblR1MulJIOtUiUpormOZc4SrmP nZ+oiReWJSFuxOlXdvdweSqjkA== X-Google-Smtp-Source: APXvYqwVGtl5Zon8WwFi3RsHofzyxLdslAyvSXLPxwg7Nt/bzSH4qqtpoJNyuCzG7vvKzwVK0tY+PQ== X-Received: by 2002:a17:906:1119:: with SMTP id h25mr3387669eja.233.1554911102638; Wed, 10 Apr 2019 08:45:02 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:20c2:134e:4f3a:683a]) by smtp.gmail.com with ESMTPSA id b34sm10458714edd.24.2019.04.10.08.45.01 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 10 Apr 2019 08:45:01 -0700 (PDT) In-Reply-To: (Drew Adams's message of "Wed, 10 Apr 2019 08:01:10 -0700 (PDT)") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::529 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:235218 Archived-At: Drew Adams writes: >> > 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 functi= on 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". Because one is a main chapter node listing standard symbol properties that one is likely to encounter, whereas the other is an appendix documenting Emacs internals. The wording of my last message may not be 100% accurate or to your liking, but it was only intended as a summary to illustrate a point. > The Elisp manual is (should be) for all Emacs users, > even users who may never write an Elisp sexp knowingly. It is and will continue to be following my next patch, if not more so. > 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. There is a balance to be reached between what is and isn't documented in the manual. The Elisp manual currently documents various internals which are very useful for someone interested in hacking on Emacs like myself. It would be a shame and disservice to remove this existing documentation or avoid updating and expanding it. The 'pure' and 'side-effect-free' properties have been prominently advertised for quite a while, and are central to the operations of the compiler optimiser. The former, in particular, is frequently used by third-party Elisp packages. I think they neither qualify as too internal to document properly, nor should have their existing documentation removed. It's just that their documentation can be reworded, expanded, and restructured in a more useful way, so that it is clearer when and how to use them; that is what Eli's review was about, and what led to Alex's question. > 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. That is exactly what I meant when I said: >> Unless someone beats me to it, I intend to try to clarify this in the >> next version of my patch. Thanks, --=20 Basil