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: named-let Date: Mon, 11 Jan 2021 18:10:17 -0500 Message-ID: References: <87im86kub6.fsf@logand.com> <86zh1g62zx.fsf@163.com> <875z4385yd.fsf@logand.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="4944"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Zhu Zihao , Tomas Hlavaty , emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 12 00:12:00 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 1kz6Lv-0001A7-R0 for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Jan 2021 00:11:59 +0100 Original-Received: from localhost ([::1]:47812 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kz6Lu-0005ti-Pf for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 18:11:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kz6KU-0004ML-4W for emacs-devel@gnu.org; Mon, 11 Jan 2021 18:10:30 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42455) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kz6KN-00061h-Ae for emacs-devel@gnu.org; Mon, 11 Jan 2021 18:10:29 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4A005440BFE; Mon, 11 Jan 2021 18:10:21 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1AB0E440A60; Mon, 11 Jan 2021 18:10:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1610406619; bh=Of33nUbm/7yyzmYVkr1YFUSCc6ug6OcrkQ2aX+/PXF0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=APZQ+Vbx6O7DIQLkzdExb9kckdUXoSSrP/RzCwHxPWsOEPE7SK+NHePndAb8sZcG+ j3AjITUIgnNeZADMunsOyRlvUYERYzlkY4RpbqhTXoVLhscdvoZbzFTVHZHDVkzbPW 4Sx8Xadg0XYNWNKbEqpvZCnuu53cK5QdR1DBSunmYYkBdoe67rZc9RAkxpnyxPYStk wYGUfsGCuhkHVQ/O8rh2BWCYvaKLQfQrSUBlmHy8svVuXvGHSy/K61J3j2SNExiAVR jjmEiTPFwCS6N5II60rcGFtwgsWWTo9fzgOJq3A6azEwVW+dH7Gb8uB8xMDakFD4QH BY9bwsgFqq0EA== Original-Received: from alfajor (unknown [45.72.224.181]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CE1DC1202BB; Mon, 11 Jan 2021 18:10:18 -0500 (EST) In-Reply-To: (Andrea Corallo's message of "Mon, 11 Jan 2021 22:50:46 +0000") 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:262949 Archived-At: >> With the advent of the native-compiler, "all implementations" is even >> harder to reach, since it means, interpreter, byte-code, and native code. > Well as I mentioned the native compiler is already capable of that if > asked, but in general whichever optimization is done by the > byte-compiler is picked by the native compiler cause currently the > compilation input is LAP. So I'm not really sure this is adding much > complexity from this POV. All the patches I've seen so far do it in the bytecode interpreter, without changing the bytecode itself. Note that it also depends on what we mean by TCO. To me, the "real TCO" is like what Scheme does (so it's not limited to recursive functions). I don't know how easy it is to implement for native-comp. Maybe GCC magically does it for us? [ TCO has also undesirable interactions with debugging/tracing, but I think that would be a secondary concern which should be manageable somehow. ] > As a side note I'd be surprised if interpreters in CL implementation are > supporting TRE, I guess the interpreter is typically used only for debug > or bootstrap therefore should be not very important. Am I wrong? I wouldn't know. But at least for ELisp , it was perceived that the plain interpreter is important enough that if it doesn't support TCO then we can't write code which relies on TCO, in which case implementing TCO in the bytecode interpreter is not very useful. [ That's part of the reason why I implemented this limited TCO as a macro: it works the same for bytecode as for any other mode of execution so it can really be considered part of the guaranteed semantics rather than a mere optimization. ] -- Stefan