[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Llorens
Subject: Re: [PATCH] Let (format) used in exceptions be overriden
Date: Mon, 22 Oct 2018 20:26:49 +0200

> 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 

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:

Here's a thread some time later:

There's a related bug:

There's a further related bug:

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



> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]