Re: R6RS exception printing at the REPL

[Andreas Rottmann]

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
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/>