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: Sun, 28 Jan 2024 17:26:03 +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="10447"; 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 18:26:55 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 1rU8vm-0002bZ-R8 for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 18:26:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rU8v7-0001Gu-M9; Sun, 28 Jan 2024 12:26:13 -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 1rU8v4-0001ER-Pz for emacs-devel@gnu.org; Sun, 28 Jan 2024 12:26:12 -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 1rU8v1-0004yo-TF for emacs-devel@gnu.org; Sun, 28 Jan 2024 12:26:10 -0500 Original-Received: (qmail 93938 invoked by uid 3782); 28 Jan 2024 18:26:04 +0100 Original-Received: from acm.muc.de (pd953ae19.dip0.t-ipconnect.de [217.83.174.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 28 Jan 2024 18:26:03 +0100 Original-Received: (qmail 12416 invoked by uid 1000); 28 Jan 2024 17:26:03 -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:315561 Archived-At: Hello, Stefan. On Sat, Jan 27, 2024 at 19:00:49 -0500, Stefan Monnier wrote: > > Evasive non-answer number 1. > That statement is mildly offensive. But justified. You did not answer the points I made and the questions I put. You gave completely unsatisfactory "answers" which didn't offer any information. You answered like a politician, swerving awkward points, and derailing the discussion onto topics the questions weren't concerned with. The main question I have is why do you want to make your change. You have given no substantial reason and evaded my continual questions to that effect. As I see it, there is not a lot wrong with the way we handle interpreted code, and I see your change as worsening it. > 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 .... See, you're doing it again. I never said nor meant "CAN" be compiled, I meant code that one wishes not to compile, for purposes of debugging or understanding. Was that not clear? So you've evaded answering my point about interpreted forms. I suppose I can't force you to answer. > .... 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. The kind of code I'm talking about is Lisp code in .el files, and examples can be found in the directory lisp and its subdirectories. The functions and macros in these can be evaluated with C-x C-e for debugging and understanding purposes. As one example, I've recently had to enhance the backquote source. This isn't easy. I'm currently able to output the lists generated by the macros without hassle, just using `message'. That will become more awkward or impossible after your proposed change, won't it? > > 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? I think 45 years of Emacs should be enough to establish the tradition. > 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. There's no disagreement. The two kinds of representation are complementary. You're proposing to abolish the list representation, or at the very least make it harder to use. That other systems may lack this representation is no reason for us to lose it. > > Your proposal will reduce these advantages. For what gain? > Since I don't think repetition helps, I'll skip this. Repetition would be unnecessary if you would just answer the question in the first place. I think I've asked that question five or six times over three posts, and you have avoided answering. Why? > > 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? Both. Also software that manipulates the printed representation of the form will be made more complicated. > 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. Your proposed patch has the bug that it dilutes and weakens the meaning of #[ ... ]. It's as if you took the meaning of the green traffic light, which unambiguously means "go" and made it mean "go unless you're driving a heavy goods vehicle", or something like that. You still haven't answered my question as to why you're using #[ ... ], and it seems likely that it was just a matter of convenience while writing your patch. It was less work. Please consider that it might not be a good idea to use it for real. > >> > 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)? I already have done. symbol-function, fset. > > What M-: (symbol-function 'foo) currently does will, I think, become > > more tedious to do. > ? `symbol-function` is unaffected. So if I write (defun foo (bar) (car bar)) into *scratch* and evaluate it, then do M-: (symbol-function 'foo), what I will get back on my terminal after your change will be exactly (closure (t) (bar) (car bar)) , will it? > > That is the extra layer of indirection. > Could it be you're confused? No, it couldn't. > Stefan -- Alan Mackenzie (Nuremberg, Germany).