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: [PATCH] * src/eval.c: Stop checking for nvars, and use only CONSP Date: Tue, 02 Mar 2021 10:48:18 -0500 Message-ID: References: <20210302.111043.609653289571449353.conao3@gmail.com> <20210302.120929.1656994339284323372.conao3@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="35329"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Naoya Yamashita , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 02 16:49:21 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 1lH7Gz-00095Q-AE for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 16:49:21 +0100 Original-Received: from localhost ([::1]:55366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lH7Gy-0001R1-CO for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 10:49:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lH7G7-0000eU-OO for emacs-devel@gnu.org; Tue, 02 Mar 2021 10:48:31 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33585) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lH7G2-00036Q-Rp for emacs-devel@gnu.org; Tue, 02 Mar 2021 10:48:25 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F1F67440843; Tue, 2 Mar 2021 10:48:20 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 77176440824; Tue, 2 Mar 2021 10:48:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1614700099; bh=m18e0D36QgGoZ9KpIRxbtBOqBDsAnppEcUquKSvu23U=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=k1vlwg1HNLPXUesWCIHU6uUSxTLTmoKwmkha7YPUCc6MaT7ry78eEOhZdZmG0mRZS h1/kmf8BVv67NILMoYfcsvcVmdwygqMgv5U8FYXd+zSTqxzWqcmbroZytiBSSrUZTx 7029BpfhG7ZwU1uSafXQiGyNmGUfB2nmJ42yN7POg4CSIc2zprMKRB64ONq3D1/B2T 7xJ8a2vnaH6h6mUOeaxdAEbUumwYEZlV7tFIBs3sbfCf/0JET23YtpjZjumNdj7LI8 KOl/2JWboN+G6NINvS/5ya99gbkqfylr/S0u0EyyOOD7HSmEMlxbRxaHDUJlHVM3cJ L6junifCUX40Q== Original-Received: from alfajor (unknown [216.154.41.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7F52C12019C; Tue, 2 Mar 2021 10:48:19 -0500 (EST) In-Reply-To: (Pip Cet's message of "Tue, 2 Mar 2021 15:19:14 +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:265838 Archived-At: >> I view the ELisp interpreter as a crutch to bootstrap the system. > Well, I view the bytecode compiler as a crutch to get to LIMPLE for > native compilation ;-) I'll get there. > I'm all for a revolution, but it might be a bit early to chop off this > particular king's head... Until we have good debugging support for byte-compiled code, the interpreter isn't going anywhere, indeed. But error reporting from the interpreter is very secondary because in my view that interpreter should only be used for bootstrap and for debugging, so all the code it executes should *also* be byte-compiled (so we can rely on the byte-compiler for error reporting). >> (defun eval (exp) (funcall (byte-compile `(lambda () ,exp)))) > Except for the ones that can't. ELC is still limited to 64K constants > in the vector, for example, isn't it? I believe so, yes. If/when we bump into this limit we can push it further (or finally replace our bytecode language with a new one ;-). > But as for the original question, do we have to have Flet? I have not seen this question asked in this thread. Stefan