Andy Wingo <wi...@pobox.com> writes:
> Oh man, at some point we have some pain coming, switching to
> srfi-35/r6rs exceptions. We mentioned it in August and decided to punt
> indefinitely -- though should someone be interested, help would be
> welcome ;-)
Yeah, we should do that. Here's an outline design.
- Core concept is that libguile exceptions are srfi-34/srfi-35 objects.
(I haven't yet checked for detailed changes between srfi-34/srfi-35
and r6rs. Are there any?)
- Back compatibility with traditional (key . args) information is
achieved by having fields in the exception object that carry this
information.
- There is a new most-fundamental primitive for raising an exception,
say scm_primitive_raise, which can take both 34/35 type+fields, and
the traditional (key . args), and constructs a 34/35 object that
encapsulates all that.
- throw maps on to scm_primitive_raise with an `unspecified throw'
34/35 type.
- error maps on to scm_primitive_raise with an `unspecified error'
34/35 type.
- libguile-generated errors/exceptions map on to scm_primitive_raise
with the most appropriate srfi-35 type, fields for that type, and the
traditional (key . args) info.
- libguile's primitive exception-handling is modified so that it just
calls the handler with the scm_primitive_raise object -
i.e. implements the semantics of with-exception-handler.
- catch and scm_*_catch_* are modified so that they wrap the supplied
handler procs in a wrapper that extracts the traditional (key . args)
from the raise object, and passes those to the handler proc.
How does that sound? Have I missed any important details?
Regards,
Neil
