[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: R6RS exception printing at the REPL
Re: R6RS exception printing at the REPL
Tue, 30 Nov 2010 00:20:37 +0100
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
Andy Wingo <address@hidden> writes:
> On Sat 27 Nov 2010 01:08, Andreas Rottmann <address@hidden> 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
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
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
>> 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
>> 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.
Andreas Rottmann -- <http://rotty.yi.org/>