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 at the REPL Date: Tue, 30 Nov 2010 00:20:37 +0100 Message-ID: <871v63vhru.fsf@delenn.lan> References: <87sjzvnu1i.fsf@delenn.lan> <87tyjbkger.fsf@delenn.lan> <87ipzj631y.fsf@delenn.lan> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291072864 19640 80.91.229.12 (29 Nov 2010 23:21:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Nov 2010 23:21:04 +0000 (UTC) Cc: ludo@gnu.org, Guile Development To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Nov 30 00:21:00 2010 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 1PND1m-0001dj-Bj for guile-devel@m.gmane.org; Tue, 30 Nov 2010 00:20:58 +0100 Original-Received: from localhost ([127.0.0.1]:39922 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PND1l-0007H2-Kn for guile-devel@m.gmane.org; Mon, 29 Nov 2010 18:20:57 -0500 Original-Received: from [140.186.70.92] (port=54584 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PND1d-0007Gn-JB for guile-devel@gnu.org; Mon, 29 Nov 2010 18:20:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PND1a-0002jM-PY for guile-devel@gnu.org; Mon, 29 Nov 2010 18:20:49 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:34436 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PND1a-0002jC-Dc for guile-devel@gnu.org; Mon, 29 Nov 2010 18:20:46 -0500 Original-Received: (qmail invoked by alias); 29 Nov 2010 23:20:44 -0000 Original-Received: from 83-215-154-5.hage.dyn.salzburg-online.at (EHLO nathot.lan) [83.215.154.5] by mail.gmx.net (mp057) with SMTP; 30 Nov 2010 00:20:44 +0100 X-Authenticated: #3102804 X-Provags-ID: V01U2FsdGVkX1/ttAgQm6btbDAlGSKl3FMdV8A8v6FRrhLwvRi0L1 l8XveUI5919Zkr Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by nathot.lan (Postfix) with ESMTP id A63CB3A695; Tue, 30 Nov 2010 00:20:43 +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 jFolt9At5b3V; Tue, 30 Nov 2010 00:20:38 +0100 (CET) Original-Received: from delenn.lan (delenn.lan [192.168.3.11]) by nathot.lan (Postfix) with ESMTP id 4F53B3A693; Tue, 30 Nov 2010 00:20:38 +0100 (CET) Original-Received: by delenn.lan (Postfix, from userid 1000) id 0DB692C0083; Tue, 30 Nov 2010 00:20:38 +0100 (CET) In-Reply-To: (Andy Wingo's message of "Mon, 29 Nov 2010 21:34:28 +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: Genre and OS details not recognized. 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:11225 Archived-At: Andy Wingo writes: > On Sat 27 Nov 2010 01:08, Andreas Rottmann writes: > >> to not lose current functionality, `print-exception' and exception >> printer procedures would need a `frame' argument as well, right? > > I guess. I never liked that, though; sounds like a needless tangling of > concerns. What does having the frame give us? Just source, or the > function name, or what? It seems like a message about the context in > which the error occurred could just as well come before the error is > printed out. > > What do you think? What does Ludovic think? :) > I share your sentiment that this is needless tangling, although I must admit I'm not at all familiar with the evolution and rationale for the design of `display-error'. Fitting that you mention this issue, since I have a question that I think also touches this area: what to do with exceptions not caught by the REPL (i.e. those leading to program termination when running a script)? My previous patch did not touch them, but I think they should be changed as well, as a crash with "guile: uncaught throw to r6rs:exception: (#)" is clearly suboptimal. However, besides the issue of how the error message should be formatted in this case (we probably need indenting for the R6RS condition representation, which is multi-line(?)), this also again raises the question of where `print-exception' should be defined, as the origin of this pre-termination error message is `default-exception-handler' in boot-9.scm. So, in my mind, this boils down to exactly define the interface of `print-exception', not only in terms of its argument list, but also in terms of the output it produces (multi-line? indented?). >>> For r6rs exceptions, I think either (rnrs conditions) or (rnrs >>> exceptions). >>> >> Ideally I'd like to put it into its own module. The exception printer >> should be able to freely use all of R6RS > > I understand the attraction of the "closure" aspects here > (R6RS-in-R6RS), but if you don't absolutely need higher levels of the > R6RS stack I would prefer for it to be implemented in (rnrs conditions) > or (rnrs exceptions), for the reason that you mention: > I think it should be managable; mainly, I just need access to `(rnrs records inspection)' and `(rnrs conditions)', so I think the latter would be an OK place to put the printer. >> `raise' and the condition system (for both the SRFI and R6RS >> varieties) are orthogonal, even if they are most often used together. > > I wasn't aware that this was the case for r6rs as well; > interesting. Well I suppose it's also possible for someone to throw > something unexpected to misc-error or to system-error. > >> A possible solution might be to allow an exception printer to decline >> to handle a specific raised object, and fall back on the default >> behavior. > >> exception-printer := port args -> boolean > > I like this suggestion; but I think the return value aspect is too > tricky. People will end up relying on the return value of whatever the > last function in the printer is, and that could be unspecified, and > indeed "unspecified values"... better to be explicit. > Yes, that's indeed a common mistake, at least in my experience. > So instead, how about > > exception-printer: port args exception-printer > > Does that make sense at all? If the given printer doesn't like the args, > it calls the default printer given to it as an arg. > Yeah, that makes sense to me. I suggest calling the parameter `punt' and recommend it being called in tail position (if at all), to facilitate the same potential looping behavior we'd get with a boolean return value, if that makes sense to you. > Anyway, so much API noodling over a small thing; but I do think it will > make Guile hacking better. > Yep, it's a needed addition, I agree. Cheers, Rotty -- Andreas Rottmann --