A slight correction...
On 09.06.2004 18:39, Denver Braughler said the following:
This way, if/when we want to parse regular expressions, JavaScript or any other "language" from Cach�, we could do it natively... Just like C/Java/Perl/etc. developers do!
Are you saying that Parser::RecDescent is actually coded in Perl? I figured it was coded in C.
No. Parse::RecDescent is pure Perl solution made by some famous Perl hacker - Damian Convey. It is not that speed optimized as the real YACC/Bison/or like parser generators (because it does its parsing of input rules on every start).
IIRC there is a more YACC-similar tool - Parse::YAPP, which does generate the static parser, which means (at least in theory) it supposed to work faster, not wasting time parsing the input rules.
Why can't tools/modules/libraries for use with Cache' be coded in C?
That way existing, vetted libraries can be used.
To me it can be "native" in the sense of integration without being written in COS itself.
If Timur writes a parser in COS, that takes standard LALR(1) and LL(1) grammars, then I am
> all for it, and I hope that ISC sees the needs and supports and distributes it.
That could be not in the nearest future, but would be fun project (and nice Proof-Of-Concept). In the nearest term it is better to try approach the less ambitious project (but very important prerequisite before even trying to create parser) - the regexp engine, powerful enough to proceed at least LEX syntax (which is limited for general usage, but quite simple). But what would be **really** useful - is to have capabilities to proceed the regular expressions in the sytax close to Perl 5.6/5.8. In this way it would be useful even outside of the small group of parser geeks. Yes, there is a PCRE C-library (which is not performance leader here, BTW), and which could be used via the standard callout mechanism. But we want don't find the easy way here (isn't it?), we want to have the pure COS solution as another POC.
Cach� already has a parser (perhaps two) for JavaScript.
Hmm. Please elaborate that you meant here? The Studio Javascript highlighter won't be of any help here.
If one could get the parse tree and feed it to Lex with a COS grammar, someone could implement <script type="text/javascript" runat="server">.
What we do need are some grammars. XHTML, CSS, and XML are defined by DTDs.
I don't think DTDs could be of very help with many parser generators. They usually uses the different form, and DTD is not exactly matches the usual BNF form expected by parser-generators.
Grammars for most programming languages can probably be found elsewhere (SourceForge?).
Most probably it would be in YACC-based format. Which is good. It means there is only need to develop something compatible with basic YACC format, and then tweak the rest manually.
Looking at our ZCacheLib projects, three, Cach� Plug-In for Eclipse, Wrench, and Studio Extensions,
> are related to grammar, particularly needing the COS grammar.
Hmm, I don't think the missing COS grammar is the show-stopper for these projects...
Just my 6e-1 Russian roubles.
Best Regards, Timur
