Well, my thesis (many moons ago I assure you) was on syntax directed editors. I came to the conclusion that letting the user do what they want is a requirement, but that "heuristics" and other "smarts" were to be avoided on the grounds that at least for my implementation they were more trouble than they were worth. Thus I would avoid error correcting parsers unless you are very confident that the correction used is at least type-safe and that it is not "sticking things in" that are unwanted (or even more maddening removing what I just typed and which **was** what I wanted). So my recommendation is that pointing out where the syntax and typing errors are without having to leave the editor would be great. Then the time required to actually make the corrections is minimal in terms of overall development time. The "interesting" (graveyard laugh) problems revolve around editing a library and the program that uses it at the same time with a few obvious extensions. The "graveyard laugh" is because I rapidly found I needed transactions and as the implementation was in C++ it had some very nasty pointer issues going to and from disk. Performance was also an issue --- but that was a a pre-sparc SUN, M68020 w/ 4Meg of RAM if memory serves me correctly. Good Luck. John Meacham wrote:
On Tue, May 30, 2006 at 10:33:05PM +0100, Brian Hulley wrote:
I was kind of hoping that the syntax of Haskell could be changed so that for any sequence of characters there would be a unique parse that had a minimum number of "gaps" inserted by the editor to create a complete parse tree, and moreover that this parse could be found by deterministic LL1 recursive descent.
a problem is that people don't write code like they write novels. At least I don't. I skip around, adding the beginning and ending of functions and going back and filling in the center, or writing the => first, then the type and going back and filling in the context. or taking existing code and changing it in pieces, deleting something there, adding it somewhere else, changing names, all of which leave intermediate states that arn't just truncated programs.
I don't see such a property actually helping that much in terms of this problem. I think you have no choice but to use heuristics to decide what the user intends and try to limit the scope of potentially incomplete source souring later things typed. Although not as popular as they once were, error correcting parsers is a fairly advanced field in computer science, combined with the knowledge of what names are in scope, I think you can come up with fairly robust heuristics. It is by no means a trivial problem, but it is certainly a tractable one.
John