> On 20 Oct 2018, at 21:36, Mark H Weaver <m...@netris.org> 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
