From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'. Date: Fri, 11 Oct 2013 12:06:55 +0300 Message-ID: <83k3hkrxao.fsf@gnu.org> References: <52576305.9000703@dancol.org> <52579C68.1040904@cs.ucla.edu> <83iox4pa0w.fsf@gnu.org> <5257AB8C.40309@dancol.org> <83eh7sp6v0.fsf@gnu.org> <5257B489.2050609@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1381482443 19778 80.91.229.3 (11 Oct 2013 09:07:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Oct 2013 09:07:23 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 11 11:07:26 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VUYgw-0005Uq-2f for ged-emacs-devel@m.gmane.org; Fri, 11 Oct 2013 11:07:26 +0200 Original-Received: from localhost ([::1]:53167 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUYgv-0002RM-65 for ged-emacs-devel@m.gmane.org; Fri, 11 Oct 2013 05:07:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUYgo-0002Na-DK for emacs-devel@gnu.org; Fri, 11 Oct 2013 05:07:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VUYgi-0007u7-68 for emacs-devel@gnu.org; Fri, 11 Oct 2013 05:07:18 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:44998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUYgh-0007tu-Ui for emacs-devel@gnu.org; Fri, 11 Oct 2013 05:07:12 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MUH00J00YN0AJ00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 11 Oct 2013 12:07:10 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MUH00J35YNX7V40@a-mtaout20.012.net.il>; Fri, 11 Oct 2013 12:07:10 +0300 (IDT) In-reply-to: <5257B489.2050609@dancol.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164080 Archived-At: > Date: Fri, 11 Oct 2013 01:19:21 -0700 > From: Daniel Colascione > CC: eggert@cs.ucla.edu, emacs-devel@gnu.org > > On 10/11/13 1:08 AM, Eli Zaretskii wrote: > > Let me rephrase: assertions are used in unoptimized code, and compile > > to nothing in optimized code. 'assume' is not needed in unoptimized > > code, since that code is grossly inefficient anyway. Thus, it sounds > > like the two are almost perfectly orthogonal > > Say we have this function: > > void foo (int *a, int *b) { *a = *a / *b; } > > Suppose it's part of foo's contract that it never be called with *b == > 0. In checked builds, we add an assertion to catch callers that violate > the contract: > > void foo (int *a, int *b) { eassert (*b != 0); *a = *a / *b; } > > Now suppose we also want the optimizer to take advantage of the fact > that *b != 0. That is a hypothetical situation. In Emacs, the code is already written on the assumption that *b != 0, so it is already "optimized" for that. In most cases, you won't see any code that can be optimized out using this assumption, as the programmer already did that -- that's why she added the assertion in the first place. IOW, assertions in Emacs code are in places where the programmer _thinks_ something must be true, and writes code based on that assumption, but she isn't really 100% sure that something to be true. So the assertion is left behind to catch the cases which the programmer missed because of her misconceptions. You are obviously thinking about a different reason of using assertions: to assert certain invariants in the code and enforce contracts of certain APIs. But that is almost never the case in Emacs, because (gasp!) almost every Emacs API has no well-defined contract at all! > > , and lumping them > > together into a single construct is likely to continue bumping upon > > problems that stem from basic incompatibility between the use cases, > > which target two different non-overlapping build types. > > Only when we have side effects. For now, yes. I'm afraid that's just the tip of the iceberg, though. > Looking through the code just now, I only saw a few assertions that > weren't obviously free of side effects. The problem is to make sure an assertion obviously _is_ free of side effects. With Emacs's massive use of macros, which call other macros, which call other macros, which... -- that is extremely hard. And why should a programmer who just wants to assert something go to such great lengths? That is just a maintenance burden for which I find no good justification. > > IOW, you should almost _never_ need to use 'assume' where you use > > 'eassert', and vice versa. So why do we need a single macro that does > > both? > > I'd actually argue that you should almost always combine assert and > assume. Not in Emacs, IMO.