From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: What happened to TCO? Date: Wed, 17 Mar 2021 22:30:13 -0400 Message-ID: References: <87k0q58kvy.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32283"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Troy Hinckley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 18 03:31:14 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lMiRN-0008JZ-Tb for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Mar 2021 03:31:13 +0100 Original-Received: from localhost ([::1]:37352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMiRM-0005iE-Vu for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Mar 2021 22:31:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50390) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMiQY-0005Bz-7x for emacs-devel@gnu.org; Wed, 17 Mar 2021 22:30:22 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22846) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMiQT-0007Gj-FY for emacs-devel@gnu.org; Wed, 17 Mar 2021 22:30:21 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CFF1980385; Wed, 17 Mar 2021 22:30:15 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5140F801F1; Wed, 17 Mar 2021 22:30:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616034614; bh=j26tlho5aBZb+XLwLHVq9bVMxlqXsB2TOiZ8G6+hDaM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Jmq/cJtmilU1Wyhv1Au8r+sKVC/3zWKxYoeClGsHvw5+o0OvMxiFKto2VjlO3Eqi2 3OCAB63cYRroHoClysdNGOPCK4RR0GbVoZZPxHP6BJrnv60hgFxOM/K9fLcdWRa1Yc oqoWA3HXHlDCokxtA/CqNMiOPqKG/kqfHWKBmftX+27/sWa95g9cLLpr/tx2p8WTNU omu1ZMjZtieS1yXJHZfLhsnAXB1dYtH9N9fc0UFNHi9HQHO0/Q93JF2F9/pCJEcpYY +Bj8gxeeoU1k2plyvd2kxRduz+kb7KLGqQ8DcAGdAFRrS8IGVSfQ+HcIbyB+gErJ9p cgnE52ajkIKgw== Original-Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 25FE6120267; Wed, 17 Mar 2021 22:30:14 -0400 (EDT) In-Reply-To: <87k0q58kvy.fsf@gmail.com> (Troy Hinckley's message of "Wed, 17 Mar 2021 16:40:01 -0600") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266541 Archived-At: > 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