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: Fri, 29 Dec 2023 13:35:56 -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="18269"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 29 19:36:57 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 1rJHj7-0004ao-Lb for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Dec 2023 19:36:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rJHiG-0004qu-1Y; Fri, 29 Dec 2023 13:36:04 -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 1rJHiD-0004qR-G7 for emacs-devel@gnu.org; Fri, 29 Dec 2023 13:36:01 -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 1rJHiB-0008On-SA for emacs-devel@gnu.org; Fri, 29 Dec 2023 13:36:01 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 822FB4427FA; Fri, 29 Dec 2023 13:35:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703874957; bh=9ZJLfGmQSJwtTDBrkFJ+IYoITBRxGTZaAwqhcQOQgwo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KAaXcRo2biuXhG8uR1JXJYWLvIEcRNcvTqG7+WJTPv8/vJ2gcH8zdQTL6ng011Msu yIVSeXTUIWhe+F4fA2RPx7961docr6NybBTOLBzzTkKwsRQTii8BAe12GrIz6TOF4L SSCKNZzngeZr9F4QwWo0ZKHBsesM8rDa88X8wCUWU5TCJ4ic48P6oskg2gyrHRPY/6 dvokaMuuCQ3ox6sBYJVRYFvCvaIf4V3/rg0Fs7y36UR7XRWHlJcjv9ayRWs6g9ZphZ 99XJPQ3ErM1HnJWNtmCyrw9Ms3jWRcRIEo80BdppWiArvh+87RbJGyKitq1tXoEEge JLhu5tayDEEbw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3D38D4427EB; Fri, 29 Dec 2023 13:35:57 -0500 (EST) Original-Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 20D7012115F; Fri, 29 Dec 2023 13:35:57 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Fri, 29 Dec 2023 17:43:05 +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:314338 Archived-At: > That's got no connection with what I wrote. What I'm asking you to > confirm is that you're not contemplating introducing error handling > machinery which, during bootstrap, will only work after Lisp code has > been loaded. The idea is: - In the short term, provide new functions that allow manipulating errors in a way that's independent from their representation (as cons cells). Hopefully this will make the code also more readable in many cases. E.g. (error-resignal ERR) instead of (signal (car ERR) (cdr ERR)). - In the longer term once enough code has been adapted to use the new functions, we may be able to consider changing the representation of error objects. Presumably error objects would then be changed from (list ERROR-TYPE DATA1 DATA2 ...) to something like (record ERROR-TYPE DATA1 DATA2 ...) This shouldn't require anything tricky during bootstrapping. But in any case we're pretty damn far from this. I'd estimate that we have at least 10 years ahead of us to decide if and how we want to make that change. -- Stefan