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 02:05:43 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30809"; 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 08:06:36 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 1rIkTT-0007lc-TC for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Dec 2023 08:06:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rIkSo-00035F-11; Thu, 28 Dec 2023 02:05:54 -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 1rIkSm-00034n-0r for emacs-devel@gnu.org; Thu, 28 Dec 2023 02:05:52 -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 1rIkSj-0000zm-2K for emacs-devel@gnu.org; Thu, 28 Dec 2023 02:05:50 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0B5568316B; Thu, 28 Dec 2023 02:05:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703747144; bh=ebJqUeZUVolA3sLdX5WuIV7GN6u+p7rNjPAsV6hncYY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MQ1GzTM5pzyYqiic0CLvucyvE0k0pCvIbXF8kOm8UB0TPfMCLRPF3s7TwBrPoIRew rtyQgl95slF61JNJGFadYRpIF7/DUfuus+d4651CPFR9XvTmHnHLLaJU5bRK/QWfVC q50UA+MwRZpwM7PvoICTq2Lt6jacDCo7qkVsxFBD7r6xgR4s1Ksx34gdK2URMGQXLW JZcuHCFxgdWnMB5UMjhiSBBWEhIA2TcCOLH37gHMBcsq6IH1SUA8OvXy36Jbr8+H6p VRM8Ez59rhHif86Vq7coLJRdB19LFkREHUtH8QsyDt2pMfzsLK8Pj/CgyJwqHANUsb Kokvyk1ZqxOxA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B31CD83169; Thu, 28 Dec 2023 02:05:44 -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 8BBDD12050C; Thu, 28 Dec 2023 02:05:44 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Wed, 27 Dec 2023 23:08:41 +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:314270 Archived-At: >> >> [ Not clear what `initialize-instance` would be used for. >> > It is passed the keyword arguments that are passed to CL:ERROR >> > or CL:SIGNAL [1,2]. >> Yes, I know, but that doesn't tell me what it lets us do that we can't >> do right now. > I guess we can do everything with symbol and cons, I don't mean "do" as in "Turing equivalent". "less work" is a good thing to "do". I just don't know in which way `initialize-instance` lets one do less work. > I'd guess the cl-averse are still doing structs with vectors :-) I don't think I'm strongly "cl-averse", but I'm rather not familiar enough with it to know its benefits. Having modified some of its code I'm familiar with its cost and what it does, but that doesn't immediately translate into ideas for how I could make good use of it. >> [ While Eric called it "slots" it holds the plist of initargs, just >> like the CLOS one. The only difference I know is that CLOS passes it = as >> an `&rest` arg. > > Yes, but it's a big one. I completely fail to see why. > Our version will go looking for slots for that each initarg and if the > slot doesn't exist it barfs, whereas in Common Lisp you can make it > &accept-other-keys. You lost me here. How does that relate to `&rest` vs `not &rest`? > I think I also wrote about this off list. In CL, make-instance can > be given arbitrary keyword args and they will show up in the > initialize-instance. They may or may not line up with a slot's > initarg. AFAIK the same thing holds for EIEIO's `initialize-instance`. > This enables us to change the data representation while > keeping the interface to the class. See the current master's > lisp/jsonrpc.el for an example where I had to use slot-missing to > get around this. I don't think this has anything to do with `&rest` or not. It sounds like a bug in `shared-initialize` or `initialize-instance` (or a disagreement between the two). I suggest you try and write a short recipe for it and make it a bug report. >> I'm afraid that doesn't tell me how to attach context to an >> error object. The context I'm talking about are orthogonal to the error >> objects themselves: any kind of context info could be attached to any >> kind of error object. > I don't know what "context" you are talking about (I guess it > was in the initial email, but I couldn't grok it). In different cases we may want to add contextual info about an error, such as the time at which it was signaled, the backtrace, some subset of the backtrace (e.g. just the name of the innermost function), or the list of files we're in the middle of loading, or some node in a datastructure within which we were operating when the error occurred, ... Usually which info to collect will depend on what it will be used for, so it's under the control of the outer code, and is thus orthogonal to the error that's signaled. >> What I mean is that if we start using something else than cons cells to >> represent error objects, loads of code will break because of things like: >> >> (condition-case err >> ... >> (error ... (signal (car err) (cdr err)))) > > Ugh indeed. 40 years of leaky abstractions, =C2=AF\_(=E3=83=84)_/=C2=AF > > So yes, "error" err would have that poor man's cons. Maybe > condition-case would only catch those? A new shiny > handler-case on the other hand, would catch proper richie > rich errors (and have the better syntax). That entails a heavy amount of churn to change old code to use that new form (while we'd want to support both for backward compatibility, we'd also want to slowly get rid of the old form to keep the overall complexity in check). The upside doesn't seem worth the cost for now. Stefan