This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Request for feedback | Implementation strategy for error linkage


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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.

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.

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.

Thank you for reading,

Charles.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJNp0lUAAoJEG9M6fiX7bE4b+YIAIirY+uvVIARa41dCIWahnnG
O4zJ1oTUQa1E2+ObnKZjA9HU/vqfvL7vd0zzcTZ4tXZr2uqGCqj648tIs09E1R5d
fnRkdMVrhRASIhFRBzPjCO1/a5Incu1xOta1arQkNpKYwrPuIcquKKWiQLltjlou
uOEA3/JnzcheM51XJh8/x2EK4UOf1eTse9tfXsga5C6CESFyzXZP3eIo+YaUnKmu
GDuaK4p4UyPqQiBFjCFb90xrpkIb9i7qJxfg65BbaiaxexGz/YA79diXg/dYAJub
Hvr3BN9BXd1MoJhFBmDJA+V+/PxF2nF8ZWFCZq1/3MnXN3sYEbAUQvkTfEHtFOM=
=qSiy
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]