[Gd-hackers] [Gd-chatter] r11662 - trunk/sandbox/cgay

[Kim Barrett]

At 11:30 AM -0800 2/5/08, Peter S. Housel wrote:
>On Mon, 2008-02-04 at 17:16 +0100, cgay at gwydiondylan.org wrote:
>  > Author: cgay
>>  Date: Mon Feb  4 17:16:14 2008
>>  New Revision: 11662
>  >
>  > [...]
>
>>  + What's the reasoning behind not having format-string and
>>    format-arguments slots in <error>, but rather putting them in
>>    <simple-error>?  This is a wart on the language.  (And why not just
>>    make it error-message instead of two separate slots?  You probably
>>    don't want to risk caching the format arguments anyway, most of the
>>    time.  [later] Is it to prevent everyone from having to import
>>    format-to-string?  Or to prevent having to do the formatting unless
>>    the error is actually signalled?)
>
>I think there's sufficient call for <error> objects that don't have
>human-readable strings.  Leaving the format in two separate components
>does indeed prevent having to do the formatting unless somebody actually
>wants to see it printed out.  If you're just going to re-throw some
>other condition then there's no point in doing the formatting.

<delurking>

No, this has nothing to do with whether <error> objects should or should
not have human-readable strings. Note that Dylan the language explicitly
doesn't specify how one gets an error message string from a condition.
The format-string / format-arguments stuff is easier to understand in the
context of an implementation-specified mechanism for getting the string
from a condition. Let's assume for the moment that it involves a "report"
function that takes a "stream" and the condition, and streams understand
some formatting protocol involving format strings. One possible
implementation of the report function would be to have a format string and
associated arguments in the condition, obtained through initialization
arguments for the condition. But there are other possible implementations.
For example, <type-error> has two initialization arguments, value: and
type:, and its report method could use those values to produce the output
written to string, possibly using a format string that is a constant in
the code for that method. Common Lisp's simple-condition (which was the
model for this bit of protocol) works that way, with simple-error &etc
being subclasses of both simple-condition and error &etc. For reasons I
don't recall (and possibly accidental), Dylan doesn't have
<simple-condition>, though perhaps some of the implementations have such
a class in an extension module.

</delurking>