From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Troy Hinckley <troyhinckley@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: What happened to TCO?
Date: Wed, 17 Mar 2021 22:30:13 -0400 [thread overview]
Message-ID: <jwva6r1gqiq.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87k0q58kvy.fsf@gmail.com> (Troy Hinckley's message of "Wed, 17 Mar 2021 16:40:01 -0600")
> I see two different patches from 2012
> https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00283.html
> https://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00477.html
> Neither was merged but I don't see any reason presented in the mailing
> list. Why were these changes not accepted?
I think the lukewarm reception discouraged them.
Also, the benefits were not made very clear: as Daniel pointed out back
then, if the TCO is only applied when byte-compiled, then you can't
always rely on it (while you can argue that interpreted code doesn't
matter to some extent, we still rely crucially on interpreted code
during the bootstrap and during Edebug sessions. We could fairly easily
circumvent the bootstrap problem, but for Edebug it requires a lot more
work). Also reliance on TCO means use of recursive calls, which may be
undesirable even with TCO if recursive calls are more expensive than
equivalent `while` loops.
So, I think TCO with the current ELisp implementation should be seen
first and foremost as an "opportunistic optimization" rather than a new
semantic feature on which code can rely. Which begs for
benchmarks showing how it affects existing code.
But we haven't seen any, AFAICT.
There are of course also potential other side-effects (e.g. impacts on
backtraces). I think these are hard to judge without actually using
such a patch for a while, so we'd probably want it to be conditional
at first.
BTW, in the meant time (i.e. quite recently), I implemented another form
of TCO (much more limited than Chris Gray's patch, since it only applies
to self recursion and only for functions defined with `cl-labels`), but
one that works both for bytecode and for interpreted code (because the
optimization is done during macroexpansion).
Stefan
next prev parent reply other threads:[~2021-03-18 2:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 22:40 What happened to TCO? Troy Hinckley
2021-03-18 2:30 ` Stefan Monnier [this message]
2021-03-18 8:41 ` Eli Zaretskii
2021-03-18 10:01 ` Andrea Corallo via Emacs development discussions.
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=jwva6r1gqiq.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=troyhinckley@gmail.com \
/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.