Request for feedback | Implementation strategy for error linkage

[Helmut Eller]

* Charles Turner [2011-04-14 19:21] writes:

> I believe I've found a dichotomy for the proposal to highlight erroneous
> sections of input. Syntactical errors discovered by the some reader as
> opposed to evaluation errors. The latter seems to present the most
> difficulty.
>
> The majority of syntactical errors are pushed into SourceMessages by a
> Lexer, it would be quite simple to add end of token information to such
> messages, though it would not be particularly elegant since different
> syntax exceptions span different amounts of source such that a general
> method for capturing the error information doesn't seem likely. The
> readObject() method of the LispReader could be modified to record the
> end of some objects position, then the handlePostfix() method of the
> same class stuffs this information into PairWithPosition's and
> LList's, ready for later processing.

[Can't say much about this]

> There's also quite of a lot of semantic decisions, such as when you
> evaluate something like '(1 . . 2), does that mean the whole list is in
> error, or just the second dot? I'd probably say the second dot, but
> maybe you'd disagree. There are lots of cases like this.

I'd say, signaling a &lexical condition at the position of the second
dot would be the most appropriate action.  Throwing a SyntaxException as
Kawa currently does is also reasonable.

> Assuming I haven't grossly underestimated what's needed above, the
> harder part is picking up evaluation errors. There's a spattering of
> exceptions that get thrown, seemingly without positional information,
> such as WrappedException and its sub-classes. Procedures are
> typically stored (it seems) in these exception classes, but whether I
> can get high (enough) resolution information from such objects remains
> questionable for me.

Most of those exceptions carry stacktraces; the stacktrace is filled in
at the point where the exception is created.  From the stacktrace you
can extract: the JVM-level class name, JVM-level method name, source
filename and source line number.  That should be enough to highlight the
source line.  Note that the JVM-level debug info does not include column
numbers or source "regions".

If you need more, then I think the most reasonable way would be to use
the JVM debugger interface (JDI); but that gets hairy quickly.

> I think the classes that require modification will likely be the
> Translator, SourceMessages, LineBufferedReader, PairWithPosition,
> UnboundLocationException, Declarations, ExpVisitor, Compliation and
> Expression. Of course, different languages will require changes to
> different sub-classes of the readers, and possibly other
> classes. The Translator class looks important in this change, it calls
> the setLocation() method of Expression's, so I could maybe try and
> change it to envelope the expression with positional information after
> the Reader has strut its stuff.
>
> I should probably stop rambling here and ask if what I'm suggesting
> sounds like a fruitful path. Of course, I haven't addressed how to
> include highlighting in the GUI, but I feel that if the information is
> available in the guts, it shouldn't be too difficult.

There's always room for improvement, but I think Kawa already collects
most of what you need.

Your REPL could in principle do something like

while (true)
  try { 
     print(eval(read()))
  } catch (Expression e) {
    <highlight error using e>
  }

You can take apart the exception object to extract the information you
need.

If you split up the eval step in a compile+execute sequence then you can
also look at the SourceMessages quite directly, which might be easier
than to figure out the info from the exception.

[Providing good source locations for errors during macro-expansion is
IMO the interesting part, but that's a story for another day.]

Helmut