Two hours ago, Ryan Culpepper wrote:
>
> I interpret "<who>: <msg>" as meaning "<who> complains that <msg>",
> whereas IIUC you want it to mean "there is a <who> such that <msg>"
> or "look at <who>; <msg>" or something like that.
>
> For procedures, it make sense whether the <who> was "application" or the
> procedure's name, but I understood a secondary goal of the overhaul to
> be to make the first line as constant as possible and move the varying
> information into the fields below.
I'm very specifically avoiding questions like what's consistent or
what's closer to what "really" happens. I'm judging the error
messages purely by the value they have for me -- in my role as a
human debugger, not as someone who's considering the exact semantics
of whatever failed. In this light, the first line of an arity error,
application: no clause matching given number of arguments
is close to useless. Not only does it not have any information that
is specific to my code, the information that it does have is obscured
by a precise-to-the-point-of-obfuscation. In fact, in the very short
time that I've been using this with other people around, I already
found myself apologizing with "oh, that's says it's an arity error".
So it's an HCI issue, and since the goal of error messages are human
consumption, I think that it's a major mistake to "waste" the very
visible top-left & the rest of the top line on something that is
precise, but carries no useful information for me. That information
is there on the second term of the second line, of course, but that
location is -- from an HCI point of view -- an extremely poor place
for the important part of the error message.
(Consider the somewhat related issue of error messages in the teaching
languages, it's a similar story.)
> I agree that having "expand" in the error message is not
> particularly helpful. But I think that putting the unbound name as
> the <who> position would be worse according to my interpretation of
^^^^^^^^^^^^^^^^^
> the first line of an error message, because 'blah' can't complain
> about anything, because 'blah' doesn't exist.
That "interpretation" is exactly the mistake I'm talking about. I
care about it too, but I care much more about getting the
information.
> "unbound identifier in module" is slightly wrong. A module can
> contain many unbound identifiers; it's only a problem is one of them
> is used as a reference.
(An excellent demonstration of my point.)
--
((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
