Re: R6RS exception printing at the REPL

[Andy Wingo]

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? :)

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