Re: Looking for a fast C++ parser

On Sat, 13 Aug 2005, Martin Ward wrote:


> A file of regexps is probably a lot easier to maintain than a handcoded state
> machine that generates the colouring on the fly.


You can get very far with a single handcoded state machine combined
with a few tables.


Let the state machine handle keywords, numbers, block comments, line
comments, a some classes of symbols and put the set of keywords in a
table, the characters that initiate comments in a table, etc.


Such a set of tables can be described very concisely in a file and is
probably easier to maintain than regular expressions.


In fact, I think that the regexps user interface is a disaster: it is
very difficult to add new languages using such an interface. Can you
add new languages to Emacs? gedit? vim? I can't.


> Maintainability is more important than efficiency for an editor (as
> long as it is still fast enough to be usable).


Vim is annoyingly slow in highlighting mode on some of my (older)
machines. The version of gedit (gnome-editor) a couple of gnome
releases back was too slow at colouring for large files on a friend's
Athlon XP. I think it is faster now but still slower than I think it
could be.


Regexps become difficult when you want greater precision in the
highlighting -- you have a bunch of rules with only "local" knowledge,
perhaps prioritized somehow. If you let the first rule that "fires"
choose the colours for the range it covers, it becomes difficult to
fine-tune the colouring. You can also turn them on or off depending
on how they "fire" but that doesn't not make the model any simpler.


No, use the generic state machine (with loadable tables) for most
languages and write dedicated state machines when you want/need better
control or the language you are trying to color is difficult (if, say,
indentation is meaningful).


-Peter

Return to the comp.compilers page.
Search the comp.compilers archives again.