From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Distinguishing `consp` and `functionp` Date: Sat, 27 Jan 2024 11:00:17 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38230"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 27 12:01:27 2024 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 1rTgRD-0009rl-BD for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jan 2024 12:01:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTgQJ-0004ld-3B; Sat, 27 Jan 2024 06:00:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTgQD-0004iM-14 for emacs-devel@gnu.org; Sat, 27 Jan 2024 06:00:29 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTgQA-0002Nk-JF for emacs-devel@gnu.org; Sat, 27 Jan 2024 06:00:24 -0500 Original-Received: (qmail 1689 invoked by uid 3782); 27 Jan 2024 12:00:19 +0100 Original-Received: from acm.muc.de (pd953ab92.dip0.t-ipconnect.de [217.83.171.146]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 27 Jan 2024 12:00:19 +0100 Original-Received: (qmail 5510 invoked by uid 1000); 27 Jan 2024 11:00:17 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315473 Archived-At: Hello, Stefan. On Thu, Jan 25, 2024 at 18:15:48 -0500, Stefan Monnier wrote: > I've been annoyed at the use of lists to represent function values for > a while now. Why? Lists are the natural representation, and traditional in Lisp. They bring all sorts of advantages (like being able to manipulate code easily in Lisp). > For a reason I cannot fathom, I even managed to reproduce that very > same mistake in Emacs-24 with the `(closure ...)` value for statically > scoped interpreted function values. > That was a major blunder. Blunder? Having (closure ...) alongside (lambda ...) is an inconvenience, yes, but ... Why a "blunder"? > In any case, I'm playing around with a "fix", making lambda evaluate > (when interpreted) not to (lambda ...) or (closure ...) but to > a self-evaluating value that can be more reliably distinguished. > In the patch below, I just reused the #[...] byte-code objects for that, > putting the function's body where the bytecode string goes and the > function's captured environment where the "constant vector" goes. Please don't do that. If you must invent a new form, then invent a new symbol to signify it. Misusing #[...] will lead to problems and extra work for everybody (as, for example, using the doc string field in oclosures for something else has led to extra work). > It's got several rough edges (most importantly that > `byte-code-function-p` returns non-nil for interpreted function > values), but it seems to work OK so far. > You can't use the patch as-is because it's written against my local > branch, with various local hacks, some of which (partly) remove support > for lexical-binding==nil. > But hopefully, it's readable enough for you to form an opinion. > WDYT? You haven't given any substantial motivation for such a change. Being "annoyed" at something is hardly grounds for making such far reaching changes. You haven't said what advantages the change would bring, beyond saying that the proposed function form will be "more easily distinguished". Any packages out there that deal with the internal format of Lisp code will be severely affected. At the very least, they'll need amendment to cope with the new format alongside the current format of code. For example, my amendments for bug #67455 (Putting position information into doc strings) are already difficult enough. This change would add a whole new layer of indirection into bug #67455's changes. > Stefan [ .... ] -- Alan Mackenzie (Nuremberg, Germany).