Yesterday, Matthew Flatt wrote:
> I don't like the way these example have the error message twice:
> once in prose and one in field-and-value form. It's difficult enough
> to get either one of those right, but it's particularly difficult to
> construct prose right, which is why the new convention encourages
> relatively static prose.
OK. I hope that the "static" aspect is going to be strong enough that
it becomes practical to build tools that use it. Ideally, the
information is going to be at such a reliable level that the prose
could be constructed automatically from the fields. In other words, I
think that for the fields, accuracy should be stressed over
readability.
(There is one point where I see this as being a problem: when you
display values, "accuracy" means that "~e" should be the same as "~s",
whereas "readability" makes it "~.s". But this could be delayed for a
possible future extension where the actual values are kept instead of
their rendering.)
> I've pushed a set of changes that moves the srcloc back to the
> front, codifies a multi-line prose format for the start of a
> message, codifies "..." as a suffix for fields that may be too noisy
> (and that an environment may choose to hide), and adjusts various
> existing error messages.
>
> We can change details like the "..." suffix, of course, but that
> amount of format/protocol change is about what seems practical and
> worthwhile to me.
How about stressing it as a possibly temporary thing that can change
in the future for some more structural approach?
(BTW, another point about using more structure is related to something
that Neil pointed: in some cases it might be expensive to compute the
information that is shown in an error, but it might be used in code
that catches the error and discards that work. This could be
addressed by using thunks (or promises) for field values.)
> Meanwhile, we should look more carefully at the content of specific
> error messages to see if we can improve either the wording or the
> information provided in fields.
+1.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
