[racket-dev] Error message structure (error-message overhaul)

The second problem I have with the error texts is their lack of
structure.  Since the error messages are much more verbose, there is
now a need to have some short form that follows conventions for
various tools.  For example:

  * There's a whole range of tools that work with the usual
    "file:line:vol: message" per line format -- Emacs compilation
    buffer, the on-line-check-syntax-like error highlighting, log
    parsers, etc.  (The emacs on-line checking is something that two
    people already noticed as a victim...)

  * In xrepl, what I did was show just the error message and omitted
    the stacktrace.  The idea is that the stacktrace is usually
    useless, so make it available but omit the default display.  This
    is no longer possible (especially with what I talked about in the
    other thread: showing just the first line results in useless
    error messages).

  * There are two contexts where error messages are unwieldy: TR and
    contract errors.  In both of these the error text is huge to the
    point of making a useless text that you need to manually grep
    through.  In TR it got bad enough that Vincent put some serious
    effort in making them shorter, and with contracts the problem is
    still there (though not as bad as TR was).  This was something
    that we talked about at some point -- consider a very likely
    mistake:

      (plot sin)

    This results in more than 80 lines of an error message, getting
    the "TR effect" where in drracket you're now staring at the
    bottom of that goop and have no clue what to make of it.  (Worse
    if that wasn't the first interaction -- since you can't also go to
    the top, you need to slowly scroll up and look for the beginning
    of the error).

    The sub-field printout could have helped here, but again since
    there's no structure it's impossible to do.

There are two problem here.  First, there's the lack of structure,
since the messages are just plain text.  A possible way to address
this is with a precise specification for the format, and then writing
an interface that pretends that there are fields.  This will probably
require some changes to the interface, like the kind of text that you
can use in `raise-arguments-error' fields, and detection of newlines
in the values.  It might also require fixing the inconsistencies that
are common now.

The second problem is worse -- without a specified meaning for the
fields, there is no way to reliably construct such one-liners.  It's
worse because a specification for the meaning of known fields will be
hard to design and harder to enforce.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!