<div dir="ltr">Nice one, thanks for the info.<div><br></div><div>I just used Pegged to generate an API for a JSON REST service at compile time so I'm still geeking out about the power of D at compile time, but I'm always interested in parsers.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 14, 2015 at 10:50 AM, Bastiaan Veelo via Digitalmars-d-announce <span dir="ltr"><<a href="mailto:digitalmars-d-announce@puremagic.com" target="_blank">digitalmars-d-announce@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Monday, 6 July 2015 at 09:22:51 UTC, Per Nordlöw wrote:<br>
</span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
How does its design and use differ from Pegged?<br>
</blockquote>
<br></span>
FWIW, this is what I learned from my first acquaintance with FancyPars (the OP having signalled not to be available for questions). My conclusions may be wrong though.<br>
<br>
Running dub produces a vibe.d web server demonstrating the capabilities of FancyPars. This was a bit confusing at first because being a web-app seemed central to the design of FancyPars, but I think it is not. Anyway, the first page shows a large edit field containing an example grammar, and a button "Generate AST". Clicking this button brings up the second page containing D code for the lexer and parser for the given grammar, type definitions for the nodes of the AST, as well as code for printing the AST.<br>
<br>
Understanding the source of FancyPars is challenging because the core source, example vibe.d application source and supporting code, as well as generated lexer/parser code are all contained in the same directory and committed in the repository.<br>
<br>
The syntax for the grammar definition is different from Pegged, and seems to be inspired by D. It supports a hierarchical structure. It looks powerful, but is undocumented. The example grammar looks like this:<br>
<br>
ASTNode {<br>
Identifier @internal {<br>
[a-zA-Z_][] identifier<br>
}<br>
<br>
Group @parent {<br>
Identifier name, ? "@" : Identifier[] annotations : "@", "{",<br>
PatternElement[] elements : "," / Group[] groups,<br>
"}"<br>
}<br>
<br>
PatternElement @internal {<br>
<br>
AlternativeElement @noFirst {<br>
PatternElement[] alternatives : "/"<br>
}<br>
<br>
LexerElement {<br>
<br>
StringElement {<br>
"\"", char[] string_, "\""<br>
}<br>
<br>
NamedChar {<br>
"char", ? "[]" : bool isArray, Identifier name<br>
}<br>
<br>
CharRange @internal {<br>
char rangeBegin, ? "-" : char RangeEnd<br>
}<br>
<br>
RangeElement {<br>
"[", CharRange[] ranges, "]"<br>
}<br>
<br>
LookbehindElement {<br>
"?lb", "(", StringElement str, ")"<br>
}<br>
<br>
NotElement {<br>
"!", LexerElement ce<br>
}<br>
<br>
}<br>
<br>
NamedElement {<br>
Identifier type, ? "[]" : bool isArray, Identifier name,<br>
? bool isArray : ? ":" : StringElement lst_sep<br>
}<br>
<br>
ParenElement {<br>
"(", PatternElement[] elements : ",", ")"<br>
}<br>
<br>
FlagElement {<br>
"bool", Identifier flag_name<br>
}<br>
<br>
QueryElement {<br>
"?", "bool", Identifier flag_name, ":", PatternElement elem<br>
}<br>
<br>
OptionalElement {<br>
"?", LexerElement[] ce : ",", ":", PatternElement elem<br>
}<br>
<br>
}<br>
}<br>
<br>
<br>
Its announced support for left-recursion is interesting, and I may decide to play a bit further with it. My objective would be to see if an Extended Pascal to D translating compiler would be feasible.<br>
<br>
Cheers,<br>
Bastiaan Veelo.<br>
</blockquote></div><br></div>