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