Design decisions when designing the core

Now that you've seen the problems associated with designing the core, examine some of the major design decisions you need to make while creating the core's architecture:

Incremental or nonincremental

As described, the choice of having an incremental or nonincremental core affects your IDE in fundamental ways. You need to decide from the beginning whether to design an incremental core.

UI or non-UI thread

If you decide to use an incremental core, you must decide whether to run the parser/lexer in a background thread or in the same thread as the editor. Running in the UI thread saves you from a lot of synchronization-related problems, but then the speed of the core will become your worst enemy (if you run in the UI thread on each keystroke, a time limit is imposed on the document analysis). Even a delay of a few milliseconds can cause a lag between the user typing a letter and it appearing on the screen, which can make using your IDE unbearable.

If you do pull it off, you can provide some cool features in your IDE that others running in a background thread will find it almost impossible to include. For example, running the analysis in the UI thread allows ANTLR Studio to provide TypeOnce functionality, which doesn't require the user to press Ctrl+Space to show auto-completions and even works when the rule name being typed hasn't been defined.

Partially incremental

Instead of having an incremental core, with everything in the IDE updating incrementally, you can have a partially incremental core. This means that instead of having both an incremental parser and an incremental lexer, you just have an incremental lexer. In the analysis part, the lexer takes 80 percent of the time, so having an incremental lexer speeds your analysis quite a bit. This way, your IDE won't need to be so complex while at the same time being fast. This is the approach taken by the NetBeans IDE.

Error-recovery strategy

You need to identify the most common form of errors your parser/lexer will face as users type code. You must then add custom code to make sure the parser can recover from these errors gracefully. Otherwise, the user's experience in your IDE will be diminished because the IDE won't have information about the code at critical points when the user needs to perform an operation, such as code completion.

9 of 12 | Previous | Next

Comments

Back to top

Table of contents

• Before you start
• Architecture
• The core
• Create a parser and lexer
• The need for speed: An inside look at the functioning of the core
• Incremental parser and lexer
• The delta
• Error recovery
• Design decisions when designing the core
• Conclusion
• Resources
• About the author

---

9 of 12 | Previous | Next

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Open source on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.