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: Distinguishing `consp` and `functionp` Date: Sat, 27 Jan 2024 19:00:49 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33441"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 28 01:01:25 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 1rTsc0-0008XN-VT for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 01:01:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTsbb-0002T7-4Z; Sat, 27 Jan 2024 19:01:00 -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 1rTsbZ-0002Ss-LP for emacs-devel@gnu.org; Sat, 27 Jan 2024 19:00:57 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTsbX-0000i1-JL for emacs-devel@gnu.org; Sat, 27 Jan 2024 19:00:57 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7ED4E100068; Sat, 27 Jan 2024 19:00:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706400052; bh=mq7KiYeADGWAHNASU/zosASrFuo2Xdj2UC72jD5B3mc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KzrM1YfoGlZlnBJGjIPWCaXCjkXdV1H6IkKKhEgbzVMmEArUrvdQ4jRAprJa8sfCZ 0jANiMfWHG+hf5w1qX9y6oIGlyAds6RGhQBDnGFrdXZVEbqqrUQcCAIIqRfl1Duboj ZTuIvb7NNnOJiMyJpRFhY7jwJa+cE+T1CsqiEhW/OCb8LVMeSjI/sLuI5Qy03mwO3D +SFRQP1idhpPO5de+6mc2uZLX+3gjKGFTJMLbER+D1FJJ7PDLe6I6RvKnL3DRFaRwe VIKFTrZTdiGW3AUDdXhGE5pXzRBujKQO8AD1TLjqidTxeiEGwSvKSP1vwHHSwRB4Fd j5P8l8DQwSAtA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3DBC710004C; Sat, 27 Jan 2024 19:00:52 -0500 (EST) Original-Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 183341202C3; Sat, 27 Jan 2024 19:00:52 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Sat, 27 Jan 2024 23:01:57 +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, 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:315504 Archived-At: > Evasive non-answer number 1. That statement is mildly offensive. I do not see what in my previous messages would call for it. [ But it may affect the rest of this message, I'm afraid. ] > We're not talking about byte or native compiled forms. We're talking > about interpreted forms. The advantages of Lisp forms had to be > foregone in the compiled forms to optimise performance. But when > being able to manipulate forms is more important than speed, then the > interpreted forms are used. Such code that can't be compiled is extremely rare and will usually be unaffected because its list-representation of a function will usually not have gone through `eval` at all. > Your plan will make this more difficult. I guess I don't really see which kind of code you're talking about: examples would help. > Let me repeat, lists are the natural, traditional representation in > Lisp, which bring all sorts of advantages. Not sure repetition helps, maybe pointing to evidence would? Common Lisp, Clojure, and Scheme, all disagree. AFAIK Lisp Machine Lisp also disagreed. And in practice the very vast majority of functions in ELisp also disagree. > Your proposal will reduce these advantages. For what gain? Since I don't think repetition helps, I'll skip this. > Evasive non-answer number 3. Where in the new structure you put the > components is independent of the symbol you use. My point wasn't about > the patch as a whole, it was about the symbol to be used for your new > form. If you press ahead with this abuse of #[...] it means that every > time somebody wants to check for a byte compiled form, they'll > additionally have to check its innards. #[ ... ] currently has an > unambiguous meaning, and it should stay that way. By "check" you mean with your own eyes? Or by calling `prin1` and parsing the result? Otherwise, I don't understand: while my current patch has the bug that it makes `byte-code-function-p` return non-nil on interpreted functions, I already mentioned that it's a problem in the patch. >> > Any packages out there that deal with the internal format of Lisp code >> > will be severely affected. >> Don't know about "severely", but yes they may be affected. There really >> aren't vry many of them, tho. > Not "may" but "will". This is an important point, not something to be > brushed aside and ignored. Work on the Emacs core will be affected, > too. The patch *does* touch those places, BTW. > Isn't it obvious? In place of being able to work on the Lisp form, > one will first have to extract it from the new structure, and then > afterwards write it back to that structure. Care to point to existing code that extracts data from a function value and then puts it back (presumably slightly modified)? > What M-: (symbol-function 'foo) currently does will, I think, become > more tedious to do. ? `symbol-function` is unaffected. > That is the extra layer of indirection. Could it be you're confused? Stefan