From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.devel Subject: Re: R6RS exception printing -- take #2 Date: Sun, 06 Feb 2011 19:09:34 +0100 Message-ID: <87mxm9xcf5.fsf@gmx.at> References: <87y660txmd.fsf@rotty.yi.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1297015807 31357 80.91.229.12 (6 Feb 2011 18:10:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Feb 2011 18:10:07 +0000 (UTC) Cc: Guile Development To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Feb 06 19:10:01 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pm93g-0003r9-8N for guile-devel@m.gmane.org; Sun, 06 Feb 2011 19:10:00 +0100 Original-Received: from localhost ([127.0.0.1]:39886 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pm93f-0000gD-GF for guile-devel@m.gmane.org; Sun, 06 Feb 2011 13:09:59 -0500 Original-Received: from [140.186.70.92] (port=42837 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pm93c-0000fz-3L for guile-devel@gnu.org; Sun, 06 Feb 2011 13:09:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pm93a-0000tg-D8 for guile-devel@gnu.org; Sun, 06 Feb 2011 13:09:55 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:39692) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Pm93a-0000sZ-1b for guile-devel@gnu.org; Sun, 06 Feb 2011 13:09:54 -0500 Original-Received: (qmail invoked by alias); 06 Feb 2011 18:09:41 -0000 Original-Received: from 83-215-154-5.hage.dyn.salzburg-online.at (EHLO nathot.lan) [83.215.154.5] by mail.gmx.net (mp011) with SMTP; 06 Feb 2011 19:09:41 +0100 X-Authenticated: #3102804 X-Provags-ID: V01U2FsdGVkX1/45UxCyHT4BVF/Zdx3hV0+tvJi2tWOSCtC6bkWih GL4uHkyVjSBiNF Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by nathot.lan (Postfix) with ESMTP id E678A3A6A5; Sun, 6 Feb 2011 19:09:39 +0100 (CET) Original-Received: from nathot.lan ([127.0.0.1]) by localhost (nathot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00C56oqGaJwt; Sun, 6 Feb 2011 19:09:35 +0100 (CET) Original-Received: from delenn.lan (delenn.lan [192.168.3.11]) by nathot.lan (Postfix) with ESMTP id 4CE853A69B; Sun, 6 Feb 2011 19:09:35 +0100 (CET) Original-Received: by delenn.lan (Postfix, from userid 1000) id EBB412C00A5; Sun, 6 Feb 2011 19:09:34 +0100 (CET) In-Reply-To: (Andy Wingo's message of "Tue, 01 Feb 2011 21:06:16 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 213.165.64.23 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:11539 Archived-At: Andy Wingo writes: > Heya Andreas, > Hi! I've attached an updated patch; see below for some points that are still to be discussed. If this patch is deemed OK, I'll work on converting all relevant sites in the REPL to use `print-exception'. > You proposed a choice between two options: > > On Tue 01 Feb 2011 01:19, Andreas Rottmann writes: > >> exception-printer := port key args exception-printer -> nothing >> exception-printer := port args thunk > > The `key' argument is necessary, at least if you want one printer to > handle multiple keys (as the default printer might). I prefer the > first, FWIW. > OK, I've now done this: exception-printer := port key args thunk -> nothing The rationale of passing in a thunk instead of an exception printer is that, to invoke the exception printer passed as last argument, the procedure would have to pass a fallback printer to *that* printer, which it can't do, as it doesn't know what that should be. Additionally, the fallback printer has to be a closure anyway, as it needs access to the `frame' argument passed to `print-exception' (see below). >> This exception registry would be used in the REPL error-handling code >> primarily, via a `print-exception' procedure querying the registry and >> invoking the matching printer (or the default one, if no printer is >> matching). > > There are other cases that it would be nice to use it: in the catch-all > in throw.c, and in general when printing exceptions from C. > I'll defer looking into that; I'll first make a follow-up patch dealing with the call sites inside the REPL code. >> Another open issue is the potential `frame' argument; it seems this is >> only used at one place in `(system repl error-handling)', inside >> `call-with-error-handling' (I did a quick grep for "display-error" and >> "Throw to" to identify the sites where I'd plug in the exception >> registry via the `print-exception' procedure). >> >> If we decide that `frame' should not be part of the exception-printer >> arguments, we'd lose source information in the exception printout in >> this case. > > Let's keep the frame out of the exception-printer functions, but still > pass it to the procedure that does the exception printing dispatch > (perhaps called print-exception or something). That way we can print > source information, then let exception printers do their thing. > The source info printing is now done only in the fallback printer, and only on "regular match" exceptions (i.e. those that have the conventional `args' structure). This is the same behavior as without the patch. However, I think it would be more consistent to always print source information if available; this would entail: - Duplicating the source-information-printing logic of `display-error' in `print-exception'. - Always call `display-error' with #f as `frame', or perhaps stop calling `display-error' and just print the exception ourselves. What do you think? >> [ Just a thought: it looks like it /might/ make sense to contemplate >> deprecating passing the frame information to `display-error' and >> untangle displaying the exception object and displaying a backtrace >> completely. ] > > There are certainly some tangles here. If you find The Right Thing, let > us know... > If we decide to do the source-information printing inside `print-exception' (as proposed above), we might think about deprecating `display-error' in favor of `print-exception'. Unfortunatly, `display-error' cannot be implemented in terms of `print-exception', as the former is missing the `key' argument that the latter requires. Regards, Rotty -- Andreas Rottmann --