Home » forums » LtU Forum

ANN: YARD Parser

I just posted to SourceForge.net the YARD parser which is a public-domain generic recursive-descent parser for C++ which is available for dwonload at SourceForge.net, documentation is also available at http://yard-parser.sf.net. The YARD parser is intended primarily to be used as lexical analyzer and syntax parser, but it is a very general purpose library. The release includes a partial XML grammar and parser. The YARD parser is intended as a simpler alternative to the boost::spirit library. Any questions or comments are welcome.

By cdiggins at 2004-12-23 23:01 | LtU Forum | previous forum topic | next forum topic | other blogs | 8841 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

i think it's great that recur

i think it's great that recursive descent parsers are appearing for c++ templates. it used to be that i'd say to people, "well, it's easy to throw a parser together... oh! you're using c++? ah, well, have you thought of switching to [insert modern functional language here]".
(maybe i was just uninformed before, but i've only noticed these recently).

By andrew cooke at Fri, 2004-12-24 17:20 | login or register to post comments

Template Metaprogramming may be Ugly

I think that template metaprogramming techniques in C++ are only just beginning to be deeply understood. Gurtovoy and Abrahams have really helped move things along with the boost::mpl library.

Template metaprogramming in C++ may be ugly, but I have found it to be a very powerful functional language. I think the problem is that most C++ programmers aren't familiar with functional programming techniques.

I have made a big effort to improve on the limitations of metaprogramming in C++ in Heron.

By cdiggins at Fri, 2004-12-24 20:08 | login or register to post comments

Cart before the horse

I think that the C++ programmers who *are* familiar with functional programming are the guys who emphasized the value of template metaprogramming. However, metaprogramming in C++ is still much much more painful and verbose than in languages like Common Lisp.

To solve this in "syntactically complex" languages (unlike Common Lisp), I think that you have to put the set of non-terminals for your language's grammar in the set of fundamental types for your language.

By Kalani at Fri, 2004-12-31 17:50 | login or register to post comments

Dylan

To solve this in "syntactically complex" languages (unlike Common Lisp), I think that you have to put the set of non-terminals for your language's grammar in the set of fundamental types for your language.

In Dylan macro definitons, you can specify the kind of non-terminal (for example expression or variable) expected at a certain place in the macro source code. But I don't think that Dylan has a type "expression" or "variable" in the language, as they are parse-time entities.

By Manu Simoni at Fri, 2004-12-31 18:08 | login or register to post comments

Macros as methods

Just define the macros as syntax-object-dispatched (multi-)methods, and provide a hook to apply them to expressions, as we've done for Slate. It's less powerful than a full pattern-matching expansion system, but it integrates much better with the language.

By Brian T Rice at Sat, 2005-01-08 10:48 | login or register to post comments