From: Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Troy Hinckley <troyhinckley@gmail.com>, emacs-devel@gnu.org
Subject: Re: What happened to TCO?
Date: Thu, 18 Mar 2021 10:01:56 +0000 [thread overview]
Message-ID: <xjf8s6kwzjf.fsf@sdf.org> (raw)
In-Reply-To: <jwva6r1gqiq.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 17 Mar 2021 22:30:13 -0400")
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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).
For completeness I just wanted to add that Tail Recursion Elimination is
already present in the native-comp branch when compiling at speed 3.
Andrea
prev parent reply other threads:[~2021-03-18 10:01 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
2021-03-18 8:41 ` Eli Zaretskii
2021-03-18 10:01 ` Andrea Corallo via Emacs development discussions. [this message]
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=xjf8s6kwzjf.fsf@sdf.org \
--to=emacs-devel@gnu.org \
--cc=akrl@sdf.org \
--cc=monnier@iro.umontreal.ca \
--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.