From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Colascione <dancol@dancol.org>
Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume'.
Date: Fri, 11 Oct 2013 12:06:55 +0300 [thread overview]
Message-ID: <83k3hkrxao.fsf@gnu.org> (raw)
In-Reply-To: <5257B489.2050609@dancol.org>
> Date: Fri, 11 Oct 2013 01:19:21 -0700
> From: Daniel Colascione <dancol@dancol.org>
> 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.
next prev parent reply other threads:[~2013-10-11 9:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1VTxwB-0001h8-7E@vcs.savannah.gnu.org>
2013-10-11 2:31 ` [Emacs-diffs] trunk r114593: * lisp.h (eassert): Don't use 'assume' Daniel Colascione
2013-10-11 6:36 ` Paul Eggert
2013-10-11 7:00 ` Eli Zaretskii
2013-10-11 7:41 ` Daniel Colascione
2013-10-11 8:08 ` Eli Zaretskii
2013-10-11 8:19 ` Daniel Colascione
2013-10-11 8:59 ` Stephen J. Turnbull
2013-10-11 9:10 ` Daniel Colascione
2013-10-11 10:27 ` Stephen J. Turnbull
2013-10-11 12:42 ` Stefan Monnier
2013-10-11 15:24 ` Stephen J. Turnbull
2013-10-11 9:06 ` Eli Zaretskii [this message]
2013-10-11 9:18 ` Daniel Colascione
2013-10-11 9:36 ` Eli Zaretskii
2013-10-11 9:55 ` Daniel Colascione
2013-10-11 10:31 ` Dmitry Antipov
2013-10-11 15:22 ` Paul Eggert
2013-10-11 15:41 ` Daniel Colascione
2013-10-12 7:37 ` Paul Eggert
2013-10-11 11:19 ` Eli Zaretskii
2013-10-11 15:57 ` Daniel Colascione
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83k3hkrxao.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dancol@dancol.org \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.