From: Philipp Stephani <p.stephani2@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Richard Stallman <rms@gnu.org>, Emacs developers <emacs-devel@gnu.org>
Subject: Re: pure-fns in byte-opt.el
Date: Sat, 25 Jul 2020 21:53:14 +0200 [thread overview]
Message-ID: <CAArVCkQRmkz3Kpt2cUu+hjfqtYxxjNhpAYiwHQuW3tAHyKikZg@mail.gmail.com> (raw)
In-Reply-To: <jwv8th2qpiw.fsf-monnier+Inbox@gnu.org>
Am Di., 26. Sept. 2017 um 02:26 Uhr schrieb Stefan Monnier
<monnier@iro.umontreal.ca>:
>
> >> pure: like side-effect-free but additionally, the function always
> >> returns the same value when called with the same arguments, so the
> >> compiler can precompute the call if it knows the arguments.
> > It may be necessary to define "same" more precisely.
> > Does it mean equal? eq?
>
> Both/neither? The compiler doesn't test it in any way (it only has the
> known arguments, and no "others" to compare it with). I guess `equal`
> is closer to what typically happens, but I don't think this precision is
> of any use. The only *real* definition is the last part: "the compiler
> can precompute the call if it knows the arguments" (where "can" should
> probably be replaced with "may", actually).
>
That's not a very useful definition, though, or rather, not a
definition at all, but a consequence of an as-yet hidden definition.
It has to be possible to decide whether a function is pure by looking
at its observable behavior and its definition. Otherwise, how are
programmers to apply the "pure" and "side-effect-free" attributes to
their functions? The behavior of the byte compiled needs to follow
from the definition, not the other way round.
(I know this thread is 3 years old, but the same topic has been
discussed in another thread as well recently, so it's not resolved.
yet)
next prev parent reply other threads:[~2020-07-25 19:53 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 2:06 pure-fns in byte-opt.el Mark Oteiza
2017-07-25 8:14 ` Andreas Schwab
2017-07-25 14:16 ` Stefan Monnier
2017-07-25 20:57 ` Philipp Stephani
2017-07-25 21:27 ` Stefan Monnier
2017-07-25 22:28 ` Clément Pit-Claudel
2017-07-26 0:08 ` Stefan Monnier
2017-07-26 7:39 ` Clément Pit-Claudel
2017-07-26 12:58 ` Stefan Monnier
2017-07-28 17:45 ` Philipp Stephani
2017-07-28 17:49 ` Stefan Monnier
2017-07-28 17:52 ` Philipp Stephani
2017-07-28 22:20 ` Stefan Monnier
2017-09-24 7:31 ` Philipp Stephani
2017-09-24 16:23 ` Stefan Monnier
2017-09-25 22:06 ` Richard Stallman
2017-09-26 0:25 ` Stefan Monnier
2020-07-25 19:53 ` Philipp Stephani [this message]
2020-07-25 19:58 ` Stefan Monnier
2020-07-25 20:08 ` Philipp Stephani
2020-07-25 20:59 ` Stefan Monnier
2020-07-29 14:21 ` Philipp Stephani
2020-07-29 14:25 ` Stefan Monnier
2017-09-24 16:26 ` Drew Adams
2017-07-26 1:00 ` Mark Oteiza
2017-07-26 14:33 ` Eli Zaretskii
2017-07-27 2:36 ` Mark Oteiza
2017-07-27 2:46 ` Stefan Monnier
2017-07-29 16:43 ` Mark Oteiza
2017-07-29 17:22 ` Eli Zaretskii
2017-07-29 19:48 ` Mark Oteiza
2017-07-29 20:03 ` Andreas Schwab
2017-07-29 20:14 ` Mark Oteiza
2017-07-27 17:06 ` Eli Zaretskii
2017-07-28 0:24 ` Mark Oteiza
2017-07-28 7:02 ` Eli Zaretskii
2017-07-29 1:24 ` Mark Oteiza
2017-07-29 7:24 ` Eli Zaretskii
2017-07-29 16:34 ` Mark Oteiza
2017-07-29 17:21 ` Eli Zaretskii
2017-09-24 7:34 ` Philipp Stephani
2017-09-24 16:24 ` Stefan Monnier
2017-09-24 23:22 ` John Wiegley
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=CAArVCkQRmkz3Kpt2cUu+hjfqtYxxjNhpAYiwHQuW3tAHyKikZg@mail.gmail.com \
--to=p.stephani2@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=rms@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.