R6RS exception printing at the REPL

R6RS exception printing at the REPL

[Andreas Rottmann]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

Hi!

Attached is a patch that improves the way R6RS exceptions are printed at
the REPL; previously:

scheme@(guile-user)> (import (rnrs))
scheme@(guile-user)> (assertion-violation 'foo "hey!" 1 2 3)
Throw to key `r6rs:exception' with args `(#<r6rs:record:&raise-object-wrapper>)'.
Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> 

With the patch:

scheme@(guile-user)> (import (rnrs))
scheme@(guile-user)> (assertion-violation 'foo "hey!" 1 2 3)
ERROR: R6RS exception:
  1. &assertion
  2. &who: foo
  3. &message: "hey!"
  4. &irritants: (1 2 3)

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: r6rs-exception-print.diff --]
[-- Type: text/x-diff, Size: 7000 bytes --]

From: Andreas Rottmann <a.rottmann@gmx.at>
Subject: Show R6RS exceptions in a reasonable way in the debugger

* module/system/repl/error-handling/r6rs.scm: New module, containing a
  formatter for R6RS exception.
* module/system/repl/error-handling.scm (error-string): Treat throws to
  `r6rs:exception' specially, calling out to `display-exception' from
  the above module.  Use `module-ref' and `resolve-module' for
  referring to that procedure to make this a runtime-only dependency.
* module/Makefile.am (SYSTEM_SOURCES): Add
  module/system/repl/error-handling/r6rs.scm.

---
 module/Makefile.am                         |    1 +
 module/system/repl/error-handling.scm      |   25 +++++---
 module/system/repl/error-handling/r6rs.scm |   93 ++++++++++++++++++++++++++++
 3 files changed, 111 insertions(+), 8 deletions(-)

diff --git a/module/Makefile.am b/module/Makefile.am
index 8086d82..3112760 100644
--- a/module/Makefile.am
+++ b/module/Makefile.am
@@ -323,6 +323,7 @@ SYSTEM_SOURCES =				\
   system/xref.scm				\
   system/repl/debug.scm				\
   system/repl/error-handling.scm		\
+  system/repl/error-handling/r6rs.scm		\
   system/repl/common.scm			\
   system/repl/command.scm			\
   system/repl/repl.scm				\
diff --git a/module/system/repl/error-handling.scm b/module/system/repl/error-handling.scm
index 737eadf..619601f 100644
--- a/module/system/repl/error-handling.scm
+++ b/module/system/repl/error-handling.scm
@@ -34,15 +34,24 @@
 ;;;
 
 (define (error-string stack key args)
-  (pmatch args
-    ((,subr ,msg ,args . ,rest)
-     (guard (> (vector-length stack) 0))
-     (with-output-to-string
-       (lambda ()
-         (display-error (vector-ref stack 0) (current-output-port)
-                        subr msg args rest))))
+  (case key
+    ((r6rs:exception)
+     (let ((display-exception
+            (module-ref (resolve-module '(system repl error-handling r6rs))
+                        'display-exception)))
+       (call-with-output-string
+         (lambda (port)
+           (display-exception stack port (car args))))))
     (else
-     (format #f "Throw to key `~a' with args `~s'." key args))))
+     (pmatch args
+       ((,subr ,msg ,args . ,rest)
+        (guard (> (vector-length stack) 0))
+        (with-output-to-string
+          (lambda ()
+            (display-error (vector-ref stack 0) (current-output-port)
+                           subr msg args rest))))
+       (else
+        (format #f "Throw to key `~a' with args `~s'." key args))))))
 
 (define* (call-with-error-handling thunk #:key
                                    (on-error 'debug) (post-error 'catch)
diff --git a/module/system/repl/error-handling/r6rs.scm b/module/system/repl/error-handling/r6rs.scm
new file mode 100644
index 0000000..200fead
--- /dev/null
+++ b/module/system/repl/error-handling/r6rs.scm
@@ -0,0 +1,93 @@
+;;; REPL error handling support for R6RS
+
+;; Copyright (C) 2010 Free Software Foundation, Inc.
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU Lesser General Public License as
+;; published by the Free Software Foundation; either version 3 of the
+;; License, or (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+;;; Code:
+
+(define-module (system repl error-handling r6rs)
+  #:export (display-exception)
+  #:use-module ((rnrs control) #:select (when unless))
+  #:use-module (rnrs records procedural)
+  #:use-module (rnrs records inspection)
+  #:use-module (rnrs conditions))
+
+(define raise-object-wrapper-obj
+    (@@ (rnrs records procedural) raise-object-wrapper-obj))
+
+(define (display-exception stack port wrapper)
+  (let ((obj (raise-object-wrapper-obj wrapper))
+        (frame (and (< 0 (vector-length stack)) (vector-ref stack 0))))
+    (cond ((condition? obj)
+           (display-error frame port #f
+                          "R6RS exception:\n~a"
+                          (list (call-with-output-string
+                                  (lambda (port)
+                                    (format-condition port obj))))
+                          '()))
+          (else
+           (display-error frame port #f
+                          "R6RS exception: `~s'" (list obj) '())))))
+
+(define (format-condition port condition)
+  (let ((components (simple-conditions condition)))
+    (if (null? components)
+        (format port "Empty condition object")
+        (let loop ((i 1) (components components))
+          (cond ((pair? components)
+                 (format port "  ~a. " i)
+                 (format-simple-condition port (car components))
+                 (when (pair? (cdr components))
+                   (newline port))
+                 (loop (+ i 1) (cdr components))))))))
+
+(define (format-simple-condition port condition)
+  (define (print-rtd-fields rtd field-names)
+    (let ((n-fields (vector-length field-names)))
+      (do ((i 0 (+ i 1)))
+          ((>= i n-fields))
+        (format port "      ~a: ~s"
+                (vector-ref field-names i)
+                ((record-accessor rtd i) condition))
+        (unless (= i (- n-fields 1))
+          (newline port)))))
+  (let ((condition-name (record-type-name (record-rtd condition))))
+    (let loop ((rtd (record-rtd condition)) (rtd.fields-list '()) (n-fields 0))
+      (cond (rtd
+             (let ((field-names (record-type-field-names rtd)))
+               (loop (record-type-parent rtd)
+                     (cons (cons rtd field-names) rtd.fields-list)
+                     (+ n-fields (vector-length field-names)))))
+            (else
+             (let ((rtd.fields-list
+                    (filter (lambda (rtd.fields)
+                              (not (zero? (vector-length (cdr rtd.fields)))))
+                            (reverse rtd.fields-list))))
+               (case n-fields
+                 ((0) (format port "~a" condition-name))
+                 ((1) (format port "~a: ~s"
+                              condition-name
+                              ((record-accessor (caar rtd.fields-list) 0)
+                               condition)))
+                 (else
+                  (format port "~a:\n" condition-name)
+                  (let loop ((lst rtd.fields-list))
+                    (when (pair? lst)
+                      (let ((rtd.fields (car lst)))
+                        (print-rtd-fields (car rtd.fields) (cdr rtd.fields))
+                        (when (pair? (cdr lst))
+                          (newline port))
+                        (loop (cdr lst)))))))))))))
+
-- 
tg: (fe15364..) t/r6rs-exception-print (depends on: master)

[-- Attachment #3: Type: text/plain, Size: 63 bytes --]


Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: R6RS exception printing at the REPL

[Andy Wingo]

On Sun 24 Oct 2010 23:46, Andreas Rottmann <a.rottmann@gmx.at> writes:

> Attached is a patch that improves the way R6RS exceptions are printed at
> the REPL

Cool! I have also found the need to define pretty-printers for various
throw keys. I wonder, could you rework this patch to add a more generic
exception-printing mechanism?

I'm going to display my ignorance in public and try to write down some
types. := is a type definition, and : declares the type of something.

  exception-printer := port args -> nothing

  set-exception-printer! : exception-printer -> nothing

  exception-printer : key -> exception-printer

  print-exception : key args port -> nothing

The default behavior could be hard-coded into print-exception. The first
two procedures (set-exception-printer!, exception-printer, and
print-exception) could go into boot-9, and the third into (system repl
error-handling), or a new module under ice-9.

What do you think?

Regards,

Andy
-- 
http://wingolog.org/

Re: R6RS exception printing at the REPL

[Andreas Rottmann]

Andy Wingo <wingo@pobox.com> writes:

> On Sun 24 Oct 2010 23:46, Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> Attached is a patch that improves the way R6RS exceptions are printed at
>> the REPL
>
> Cool! I have also found the need to define pretty-printers for various
> throw keys. I wonder, could you rework this patch to add a more generic
> exception-printing mechanism?
>
Sure, that would make sense, and I can then also squash all the
occurances where exceptions are printed that I've missed in the last
patch.

> I'm going to display my ignorance in public and try to write down some
> types. := is a type definition, and : declares the type of something.
>
>   exception-printer := port args -> nothing
>
>   set-exception-printer! : exception-printer -> nothing
>
Did you mean the following?

set-exception-printer! : key exception-printer -> nothing

>   exception-printer : key -> exception-printer
>
>   print-exception : key args port -> nothing
>
> The default behavior could be hard-coded into print-exception. The first
> two procedures (set-exception-printer!, exception-printer, and
> print-exception) could go into boot-9, and the third into (system repl
> error-handling), or a new module under ice-9.
>
Sorry, I don't understand this -- there are three procedures, which you
all say should go into boot-9.scm?  Or did you mean that
`print-exception' should go into `(system repl error-handling)'?

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

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: R6RS exception printing at the REPL

[Andy Wingo]

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?

>> 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).

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.

Thanks for the patch, and for dealing with a fickle maintainer!

Andy
-- 
http://wingolog.org/

Re: R6RS exception printing at the REPL

[Andreas Rottmann]

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

@ and @@ in r6rs libs [Was: R6RS exception printing at the REPL]

[Andy Wingo]

On Sat 27 Nov 2010 01:08, Andreas Rottmann <a.rottmann@gmx.at> writes:

> [ 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... ]

Agreed, FWIW; to the extent that it's possible anyway. For me it's also
fine to have auxiliary modules in the rnrs namespace, if needed to break
cycles.

Andy
-- 
http://wingolog.org/

Re: R6RS exception printing at the REPL

[Andy Wingo]

On Sat 27 Nov 2010 01:08, Andreas Rottmann <a.rottmann@gmx.at> 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/

Re: @ and @@ in r6rs libs [Was: R6RS exception printing at the REPL]

[Andreas Rottmann]

Andy Wingo <wingo@pobox.com> writes:

> On Sat 27 Nov 2010 01:08, Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> [ 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... ]
>
> Agreed, FWIW; to the extent that it's possible anyway. For me it's also
> fine to have auxiliary modules in the rnrs namespace, if needed to break
> cycles.
>
I'll look into this when I have some extranous time on my hands; I think
`(rnrs private ...)' seems like a decent choice for modules internal to
the R6RS implementation, although I'm of course open to suggestions.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: R6RS exception printing at the REPL

[Andreas Rottmann]

Andy Wingo <wingo@pobox.com> writes:

> On Sat 27 Nov 2010 01:08, Andreas Rottmann <a.rottmann@gmx.at> 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/>

Re: R6RS exception printing at the REPL

[Ludovic Courtès]

Hello there!

Andy Wingo <wingo@pobox.com> writes:

> On Sat 27 Nov 2010 01:08, Andreas Rottmann <a.rottmann@gmx.at> 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 don’t think, actually.  :-)

Well, at first I thought exception printers could be nice.  Currently,
there’s a single exception printer, which makes assumptions about the
arguments to ‘throw’.  Namely, it expects (throw KEY FUNC FORMAT-STRING
FORMAT-ARG ...), or something like that.  When that is honored,
exceptions are displayed in a human-readable way, otherwise they are
(very) badly printed, which could be improved.

OTOH, exceptions are a programming mechanism, not a UI mechanism, so one
could argue that it’s up to the application to define how to present
exceptions to the user.

I think I’m slightly skeptical about system-wide exception printers
because of this, and also because system-wide settings are evil.

Thanks,
Ludo’.

Re: R6RS exception printing at the REPL

[Ludovic Courtès]

Andreas Rottmann <a.rottmann@gmx.at> writes:

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

While I just said I’m skeptical about global exception printers, I agree
that exception printing as in this example should be improved.  So, hmm,
perhaps global exception printers are unavoidable?

Thanks,
Ludo’.

Re: R6RS exception printing at the REPL

[Andreas Rottmann]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello there!
>
> Andy Wingo <wingo@pobox.com> writes:
>
>> On Sat 27 Nov 2010 01:08, Andreas Rottmann <a.rottmann@gmx.at> 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 don’t think, actually.  :-)
>
> Well, at first I thought exception printers could be nice.  Currently,
> there’s a single exception printer, which makes assumptions about the
> arguments to ‘throw’.  Namely, it expects (throw KEY FUNC FORMAT-STRING
> FORMAT-ARG ...), or something like that.  When that is honored,
> exceptions are displayed in a human-readable way, otherwise they are
> (very) badly printed, which could be improved.
>
Well, the point is that for R6RS and SRFI-34 exceptions, this convention
is never honored, and it makes perfect sense IMO to introduce a
mechanism that allows Guile to deal with alternative conventions already
present in its code base.

> OTOH, exceptions are a programming mechanism, not a UI mechanism, so one
> could argue that it’s up to the application to define how to present
> exceptions to the user.
>
AFAIU, the proposed API is there to influence the presentation of
exceptions that are _not_ handled by the application.  The achieved
better representation of exceptions is a convinience for developers, and
not something that should make a difference for the user of a
Guile-based application, in the absence of any bugs in said application.
If there is a bug, however, and thus an exception escapes to Guile's
exception handler, a better presentation will allow for better bug
reports (again, a convinience for the developer).

> I think I’m slightly skeptical about system-wide exception printers
> because of this, and also because system-wide settings are evil.
>
I somewhat share that sentiment -- the global registry feels a bit
awkward; perhaps it should be stored in a fluid?  Also, I'd rather have
the proposed API be Guile-internal, but I don't know how to properly
achieve that.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: R6RS exception printing at the REPL

[Ludovic Courtès]

Hi,

Andreas Rottmann <a.rottmann@gmx.at> writes:

> I somewhat share that sentiment -- the global registry feels a bit
> awkward; perhaps it should be stored in a fluid?

Yes, possibly.  Should at least be more flexible.

> Also, I'd rather have the proposed API be Guile-internal,

+1

> but I don't know how to properly achieve that.

Unfortunately, we don’t really have mechanisms to achieve this.  So the
best you can do is add a comment stating that the objects are for
internal use only...

Thanks,
Ludo’.