Re: R6RS exception printing at the REPL
Hi, Andreas Rottmann a.rottm...@gmx.at writes: I somewhat share that sentiment -- the global registry feels a bit awkward; perhaps it should be stored in a fluid? Yes, possibly. Should at least be more flexible. Also, I'd rather have the proposed API be Guile-internal, +1 but I don't know how to properly achieve that. Unfortunately, we don’t really have mechanisms to achieve this. So the best you can do is add a comment stating that the objects are for internal use only... Thanks, Ludo’.
Re: R6RS exception printing at the REPL
l...@gnu.org (Ludovic Courtès) writes: Hello there! Andy Wingo wi...@pobox.com writes: On Sat 27 Nov 2010 01:08, Andreas Rottmann a.rottm...@gmx.at 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 don’t think, actually. :-) Well, at first I thought exception printers could be nice. Currently, there’s a single exception printer, which makes assumptions about the arguments to ‘throw’. Namely, it expects (throw KEY FUNC FORMAT-STRING FORMAT-ARG ...), or something like that. When that is honored, exceptions are displayed in a human-readable way, otherwise they are (very) badly printed, which could be improved. Well, the point is that for R6RS and SRFI-34 exceptions, this convention is never honored, and it makes perfect sense IMO to introduce a mechanism that allows Guile to deal with alternative conventions already present in its code base. OTOH, exceptions are a programming mechanism, not a UI mechanism, so one could argue that it’s up to the application to define how to present exceptions to the user. AFAIU, the proposed API is there to influence the presentation of exceptions that are _not_ handled by the application. The achieved better representation of exceptions is a convinience for developers, and not something that should make a difference for the user of a Guile-based application, in the absence of any bugs in said application. If there is a bug, however, and thus an exception escapes to Guile's exception handler, a better presentation will allow for better bug reports (again, a convinience for the developer). I think I’m slightly skeptical about system-wide exception printers because of this, and also because system-wide settings are evil. I somewhat share that sentiment -- the global registry feels a bit awkward; perhaps it should be stored in a fluid? Also, I'd rather have the proposed API be Guile-internal, but I don't know how to properly achieve that. Regards, Rotty -- Andreas Rottmann -- http://rotty.yi.org/
Re: R6RS exception printing at the REPL
Hello there! Andy Wingo wi...@pobox.com writes: On Sat 27 Nov 2010 01:08, Andreas Rottmann a.rottm...@gmx.at 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 don’t think, actually. :-) Well, at first I thought exception printers could be nice. Currently, there’s a single exception printer, which makes assumptions about the arguments to ‘throw’. Namely, it expects (throw KEY FUNC FORMAT-STRING FORMAT-ARG ...), or something like that. When that is honored, exceptions are displayed in a human-readable way, otherwise they are (very) badly printed, which could be improved. OTOH, exceptions are a programming mechanism, not a UI mechanism, so one could argue that it’s up to the application to define how to present exceptions to the user. I think I’m slightly skeptical about system-wide exception printers because of this, and also because system-wide settings are evil. Thanks, Ludo’.
Re: R6RS exception printing at the REPL
Andreas Rottmann a.rottm...@gmx.at writes: 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: (#r6rs:record:raise-object-wrapper) is clearly suboptimal. While I just said I’m skeptical about global exception printers, I agree that exception printing as in this example should be improved. So, hmm, perhaps global exception printers are unavoidable? Thanks, Ludo’.
Re: R6RS exception printing at the REPL
On Sat 27 Nov 2010 01:08, Andreas Rottmann a.rottm...@gmx.at 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? :) 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: the separate-module approach will not work with the proposed exception printer registry unless the module registering the handler is actually loaded So let's keep the mechanism simple, if possible. `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. 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. Anyway, so much API noodling over a small thing; but I do think it will make Guile hacking better. Cheers, Andy -- http://wingolog.org/
Re: R6RS exception printing at the REPL
Andy Wingo wi...@pobox.com writes: On Sat 27 Nov 2010 01:08, Andreas Rottmann a.rottm...@gmx.at 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: (#r6rs:record:raise-object-wrapper) 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 -- http://rotty.yi.org/
Re: R6RS exception printing at the REPL
Andy Wingo wi...@pobox.com writes: Heya Andreas, On Sat 20 Nov 2010 19:18, Andreas Rottmann a.rottm...@gmx.at writes: Andy Wingo wi...@pobox.com writes: set-exception-printer! : exception-printer - nothing Did you mean the following? set-exception-printer! : key exception-printer - nothing Of course, yes. It seems I distilled the interface down past its essentials! ;) :-) Did you mean that `print-exception' should go into `(system repl error-handling)'? This, that print-exception could go into (system repl error-handling). The reason for this would be to allow the default exception printer, embedded in print-exception, to use other modules, like match or pmatch or the like. I think? That sounds like a good idea. I just sat down to implement this, and noticed that, to not lose current functionality, `print-exception' and exception printer procedures would need a `frame' argument as well, right? What do you think? Besides the above questions, I wonder where I should install the exception printer for R6RS exceptions (since the code will depend on quite a bit of R6RS, so we maybe want to have it loaded on demand, like in the last patch. Good question. 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, and I'd like to avoid making the already complicated relationships between the modules implementing R6RS even more so by introducing additional imports or `@'-references into either of these modules. I'm aware, however, that the separate-module approach will not work with the proposed exception printer registry unless the module registering the handler is actually loaded; perhaps registering a printer in `(rnrs exceptions)' that lazy-loads the module actually implementing the printer would work, but maybe that would be too hairy? [ It's off-topic in this thread, but I think the circular dependencies introduced by using `@' and `@@' in the R6RS modules should at one point be eliminated; they work almost all the time, but can fail in surprising ways -- see the commit comment of c0f6c163... ] For srfi-35 conditions, either we make another registry for printers of srfi-34 [sic] exceptions, or just assume that people using srfi-34 probably want srfi-35 as well, and have srfi-35 define the printer for srfi-34 exceptions. Hmm, that's a kind of a tricky question, since `raise' and the condition system (for both the SRFI and R6RS varieties) are orthogonal, even if they are most often used together. 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. If we do that, it might even make sense to allow multiple printers per throw key. So the API would change just a small bit: exception-printer := port args - boolean Regards, Rotty -- Andreas Rottmann -- http://rotty.yi.org/
Re: R6RS exception printing at the REPL
On Sun 24 Oct 2010 23:46, Andreas Rottmann a.rottm...@gmx.at writes: Attached is a patch that improves the way R6RS exceptions are printed at the REPL Cool! I have also found the need to define pretty-printers for various throw keys. I wonder, could you rework this patch to add a more generic exception-printing mechanism? I'm going to display my ignorance in public and try to write down some types. := is a type definition, and : declares the type of something. exception-printer := port args - nothing set-exception-printer! : exception-printer - nothing exception-printer : key - exception-printer print-exception : key args port - nothing The default behavior could be hard-coded into print-exception. The first two procedures (set-exception-printer!, exception-printer, and print-exception) could go into boot-9, and the third into (system repl error-handling), or a new module under ice-9. What do you think? Regards, Andy -- http://wingolog.org/
Re: R6RS exception printing at the REPL
Heya Andreas, On Sat 20 Nov 2010 19:18, Andreas Rottmann a.rottm...@gmx.at writes: Andy Wingo wi...@pobox.com writes: set-exception-printer! : exception-printer - nothing Did you mean the following? set-exception-printer! : key exception-printer - nothing Of course, yes. It seems I distilled the interface down past its essentials! ;) Did you mean that `print-exception' should go into `(system repl error-handling)'? This, that print-exception could go into (system repl error-handling). The reason for this would be to allow the default exception printer, embedded in print-exception, to use other modules, like match or pmatch or the like. I think? What do you think? Besides the above questions, I wonder where I should install the exception printer for R6RS exceptions (since the code will depend on quite a bit of R6RS, so we maybe want to have it loaded on demand, like in the last patch. Good question. For r6rs exceptions, I think either (rnrs conditions) or (rnrs exceptions). For srfi-35 conditions, either we make another registry for printers of srfi-34 [sic] exceptions, or just assume that people using srfi-34 probably want srfi-35 as well, and have srfi-35 define the printer for srfi-34 exceptions. Thanks for the patch, and for dealing with a fickle maintainer! Andy -- http://wingolog.org/
