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: Attaching context info to an error Date: Thu, 28 Dec 2023 11:03:43 -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="16777"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 28 17:04:46 2023 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 1rIssH-00041L-OT for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Dec 2023 17:04:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rIsrP-00005u-DI; Thu, 28 Dec 2023 11:03:51 -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 1rIsrO-0008Uk-HB for emacs-devel@gnu.org; Thu, 28 Dec 2023 11:03:50 -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 1rIsrM-0006Vl-II for emacs-devel@gnu.org; Thu, 28 Dec 2023 11:03:50 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C2F60831F3; Thu, 28 Dec 2023 11:03:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703779425; bh=TcDsFgGWtuimH81lB7D931GdWGRodyu3AF3rQvi+ojk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Y1zG24pB20cDkWpav9AoRCjvBtOPKNO0vtJqpkquw57vm1ZjzouoVjP8jOH1AMBsu l+c1WvxGMoZNy5Sgu8cJkI5v8y8CSVY7l62WXGj7sCqnTfLnaGalHt7JRpEUfZWkZZ AsyhEoh3XNmE9LMN6N1uB67qnJUV6ICL84rv+yQfxXO7dG/uLC5Y11SVNhM0VO/uqO bGdbIFH7xV/S5QRfzQSjF7rjq4XZXPnrEHtx/ZKAW32MFViOH794xwD3e3syn+Sem9 nFododw22+OAXPgb54mo7uxdx7shCvVsbwdF+jmKKlF6y1G9gLEoXE6ZPOyjGRZtw6 qrw7moDSR6a6A== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 730BB83096; Thu, 28 Dec 2023 11:03:45 -0500 (EST) Original-Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4E81D121197; Thu, 28 Dec 2023 11:03:45 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Thu, 28 Dec 2023 14:12:09 +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:314285 Archived-At: > It's not just initialize-instance, of course, it's CLOS or > an equivalent. You wrote: [...] And then, CLOS is good :-) you get access to lots of existing useful protocols. initialize-instance, print-object, etc for free. Which implies that `initialize-instance` is a useful protocol. I'd just be happy to see a concrete example of something useful you can do with it that's easier than what we do with "old style Lisp". > Top of my head, CLOS gives you hierarchies easily, with generic > functions doing the right thing by default when called with an > instance of the subclass. You do realize that I wrote `cl-generic.el`, made changes to `cl-defstruct` to better integrate with EIEIO, ... > That's the "standard method combination" [1], ... and this as well, right? > *** Welcome to IELM *** Type (describe-mode) or press C-h m for help. > ELISP> (defclass foo () ((bar :initarg :bar) (baz :initarg :baz))) > foo > ELISP> (make-instance 'foo :bar 42 :baz 42) ; so far so good > # > ELISP> (defclass foo () ((bar :initarg :bar))) ; redef > foo Redefinition of a class is definitely not currently supported (with no plan to support it in the foreseeable future). But in the `jsonrpc.el` there is no redefinition, so it seems to be another problem. Can you open a bug with a small recipe that reproduces the problem that you encountered while writing `jsonrpc.el`? > In summary, I think the "context" you are thinking about can just > be good old dynamic context, i.e. let-bindings of special > variables, with the new HANDLER-BIND-powered twist that these > variables can remain private to their users _and_ be augmented > after they are initially established. > > Right? Wrong? That describes where the context is placed until the error is signaled. The question is how/where to preserve (part of) this context information when some code wants to use it *after* unwinding the stack. E.g. in `bytecomp.el` on the handler-bind branch I solved it as follows: (let ((form-stack nil)) (condition-case error-info (handler-bind ((error (lambda (_err) (setq form-stack byte-compile-form-stack)))) (funcall body-fn)) (error (let ((byte-compile-form-stack form-stack)) (byte-compile-report-error error-info)))))))) where `byte-compile-form-stack` is basically your *FOO-DATA*, and I preserve/propagate this info by stashing it in the `form-stack` variable. Maybe we could have gotten away with calling `byte-compile-report-error` directly from the `handler-bind` handler, but that could be affected by all kinds of dynamic let-bindings and whatnot. Another example is in the C code: when we call `signal`, the C code walks the backtrace to find the name of the inner function, stores it in the global `Vsignaling_function` and then uses it in `cmd_error(_internal)` (i.e. after unwinding the stack) to include it in the error message. The us of a global var here is not just ugly but it's also wrong because other ELisp code can be executed between the moment we store the info in the var and the moment we use it, so it can be polluted by the info from some other error. [ And yes, we could rewrite that code to do something like what I did in `bytecomp.el` above. ] >> The upside doesn't seem worth the cost for now. > It'll be harder 40 years from now. I guess we'll see :-) Stefan