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 23:01:57 +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="35339"; 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 Sun Jan 28 00:02:47 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 1rTrhH-00090w-70 for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 00:02:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTrgq-0005tj-5E; Sat, 27 Jan 2024 18:02:20 -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 1rTrgo-0005tN-5b for emacs-devel@gnu.org; Sat, 27 Jan 2024 18:02:18 -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 1rTrgl-0008EH-Pp for emacs-devel@gnu.org; Sat, 27 Jan 2024 18:02:17 -0500 Original-Received: (qmail 62960 invoked by uid 3782); 28 Jan 2024 00:02:00 +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; Sun, 28 Jan 2024 00:02:00 +0100 Original-Received: (qmail 12175 invoked by uid 1000); 27 Jan 2024 23:01:57 -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:315500 Archived-At: Hello, Stefan. On Sat, Jan 27, 2024 at 09:25:10 -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). > Not sure how that relates. When the code is byte-compiled we already > can't access the function as a plain list. And when it's native > compiled, we literally can't access its internals from Lisp. at all. Evasive non-answer number 1. 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. Your plan will make this more difficult. Let me repeat, lists are the natural, traditional representation in Lisp, which bring all sorts of advantages. Your proposal will reduce these advantages. For what gain? > > Blunder? Having (closure ...) alongside (lambda ...) is an > > inconvenience, yes, but ... Why a "blunder"? > Because we could have easily used #[closure ...] instead and the problem > would be mostly solved by now :-) Evasive non-answer number 2. What is the advantage of #[closure ...] over (closure ...)? I can see only disadvantages. > > 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). > Actually, if you look at the patch, you'll see that the change tends to > reduces the amount of work that's needed elsewhere because docstrings > and interactive-forms are now found at the same place for interpreted > and (byte-)compiled functions. 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. > > 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. > > For example, my amendments for bug #67455 (Putting position information > > into doc strings) are already difficult enough. > I'll gladly take care of making the necessary adjustements. That's just an example to make a point. _ALL_ similar work on the core will become more difficult if you press ahead with this change. > > This change would add a whole new layer of indirection into bug > > #67455's changes. > I don't see how/why. 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. What M-: (symbol-function 'foo) currently does will, I think, become more tedious to do. That is the extra layer of indirection. > In the worst case, it will replace one special case with another. No. It will just make things more difficult, full stop. Or can you identify something in your change which will make development easier? Again, why? What is the advantage this proposal of yours is supposed to bring? So far, all I've seen in the thread is tiny things about the ability to do (funcall '(lambda ...)), the ability to cl-prin1 functions obfuscated and suchlike. Why? > Stefan -- Alan Mackenzie (Nuremberg, Germany).