Re: re2c-1.0 released!

> However, you raise an interesting point. There are plenty of regexes I
> use at work that are fixed, so they could indeed just use generated
> code to save the construction cost at runtime. The only reason I
> haven't done this up until now is that it makes maintenance easier to
> just have a string you can tweak directly in the source. The holy
> grail (I believe) is sufficiently powerful meta-programming to do the
> whole thing at compile time, although you could of course do it today
> with custom build steps to generate code via re2c or whatever other
> tool (that kind of thing tends to scare developers where I work).


I think in future C++ will add compiled regular expressions as a
language extension. It seems logical in a compiled language, and it
would definitely simplify the toolchain.




> I'm currently playing with searching using LALR(1) grammars and have
> written a search tool gram_grep which I will be extending soon. I
> would like to put together an LR(*) algorithm to make defining rules
> easier for people, but I don't know when I'll have the time to really
> get into that.


At some point I also wrote a LALR(1) parser generator which main feature
is generating direct-code parsers (as opposed to table-based parsers
generated e.g. by bison). In my case (parsing JavaScript) it resulted in
about 2x speedup over bison's parser (minus one dereference on each
iteration of the parser loop). Maybe you would also like to experiment
with this approach (a.k.a. 'recursive ascent').




Ulya
[If you want C++ extended with RE's, that's essentially what flex is. -John]

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