Re: R6RS exception printing at the REPL

[Andreas Rottmann <a.rottmann@gmx.at>]

Andy Wingo <wingo@pobox.com> writes:

> Heya Andreas,
>
> On Sat 20 Nov 2010 19:18, Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> Andy Wingo <wingo@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/>