Re: [PATCH] Let (format) used in exceptions be overriden

[Daniel Llorens]

> On 20 Oct 2018, at 21:36, Mark H Weaver <address@hidden> wrote:
>>  replace uses of (format) by (exception-format).
> 
> What's the rationale for this proposed change?
> 
> ...


Hi Mark,

I don't know how that just ended on guile-devel. It's part of a patch series I 
sent last year and I don't remember reposting it. However, now that we're 
here...

I agree with your comments, this patch is a crude hack. I am not proposing it 
for inclusion in Guile. However the issue that prompted that patch is still 
outstanding. I depend on the patch myself to be able to use Guile.

The original post is here:

        https://lists.gnu.org/archive/html/guile-devel/2017-02/msg00009.html

Here's a thread some time later:

        https://lists.gnu.org/archive/html/guile-devel/2017-03/msg00053.html

There's a related bug:

        https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29684

There's a further related bug:

        https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29669

I believe the latter bug is solved with repl-option-set!. That's undocumented 
(and perhaps not very friendly). ,o print is kind of documented 
(https://www.gnu.org/software/guile/manual/html_node/System-Commands.html), 
although an example would be useful there.

I didn't see an equivalent for exception messages. I saw Ludovic's mention of 
set-exception-printer! (undocumented) and tbh I haven't tried to see if that 
could work. I haven't looked into customizing current-error-port either.

Now I think that printing truncated output by default (for either repl output 
or exception printers) would be better than the current situation. If the user 
wants to check the full objects in the error message they can always backtrace, 
and not every object has a useful representation anyway. truncated-print has 
bad performance cases, but those should be fixable.

But I don't think it's reasonable to format ~a an arbitrary object at the 
exception site.

Regards

        Daniel



> All but one of the occurrences of 'format' that you replaced had a
> literal (i.e. constant) format string that only uses the escapes
> supported by 'simple-format', so I'm not sure why you need those to be
> overridden.
> 
> The only occurrence with a non-literal format string that you changed is
> in 'false-if-exception', in the case when the #:warning keyword is
> passed by the user along with a template string and arguments.
> 
> In general, I'd like to strongly discourage the practice of modifying
> global variables to swap in extended variants of widely used procedures
> such as format.  That method breaks down badly when two different
> modules try to extend core functionality in different ways.
> 
> If you want to make 'false-if-exception' extensible, I would prefer to
> instead provide a third syntax that allows the user to pass a custom
> 'format' procedure.
> 
> What do you think?
> 
>    Regards,
>      Mark