| How to control the ParseController / how much should I do in ParseController.parse()? [message #765646] |
Wed, 14 December 2011 12:58 |
 Ingo 
Messages: 1
Registered: December 2011 |
Junior Member |
|
|
Hello,
first, I want to express my respect and admiration for the creators of IMP. I find the IMP approach (you already have a language, only the IDE is missing) very appealing; and indeed, I was able to implement a basic IDE (up to now supporting preference pages, syntax coloring, error messages and a builder with error markers) in a few weeks with only moderate modifications in my existing compiler (the lexer used to record line and column numbers for the tokens, but for the IDE one needs character offsets from the beginning of the source code also).
That being said, the code generated by *.pfsp specifications gave me some headaches, as it is buggy (at least in the presence of color choosers). Moreover, there does not seem to be a language description for pfsp? Anyway, those are minor disturbances.
The structure of my compiler (for the Frege programming language (can't post link here), just in case anyone wants to know) is such that it proceeds in several passes:
1. lexical analysis turns a character sequence into a token sequence
2. syntax analysis is done by a yacc generated parser
3. - 13. various passes perform various transformations on the AST or elements thereof
14. type checker does type inference
15. ... more transformations, optimizations etc. up to code generation.
Every pass needs an error free outcome of the previous passes. For example, it makes no sense to do type inference on a syntactically invalid expression.
Hence, in my ParseController.parse(...) I basically do the following:
pass = 1
errors = 0
while (errors == 0 && pass <= 14 && !monitor.cancelled()) {
run pass
report errors and update error counter
pass++
}
The idea is to go up to and including type inference, which produces the most important error messages and, if it succeeds, provides worthy information like the exact type of every item in the program (which I intent to make use of later in the hover service). Unfortunately, it may take a while (1 to 2 seconds for medium sized programs) to complete it.
Hence I am in doubt whether this approach is the right one, given that the whole process is not only done on every character typed, but on various other occasions also. For example, when typing CTRL+S, the builder will be started (good!), but also a (IMHO needless) ParseController.parse() (why? nothing changed).
The behaviour when one types a few characters very fast is also not quite clear. It looks like multiple ParseController.parse()s are started almost parallel on the same ParseController instance?
Here are my questions:
- Do I have to write the ParseController methods in a thread safe manner? Can I use synchronized blocks/methods to sequentialize or could this block the whole Eclipse machinery?
- I'd like to arrange it so that ParseController.parse() is called not on every single character but rather when the user pauses typing, say for 300ms. How can I achieve this?
- When exactly is getTokenIterator() called (apparently, quite often), and how to control that?
- Any comments or suggestions on my approach outlined above?
|
|
|
Powered by
FUDForum. Page generated in 0.02696 seconds
] 
Search
Help
Register
Login
Home
