On Monday, 6 July 2015 at 09:22:51 UTC, Per Nordlöw wrote:

How does its design and use differ from Pegged?

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.

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.

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.

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:

ASTNode {
    Identifier @internal {
        [a-zA-Z_][] identifier
    }

    Group @parent {
        Identifier name, ? "@" : Identifier[] annotations : "@", "{",
            PatternElement[] elements : "," / Group[] groups,
             "}"
    }

    PatternElement @internal {

        AlternativeElement @noFirst {
            PatternElement[] alternatives : "/"
        }

        LexerElement {

            StringElement {
                "\"", char[] string_, "\""
            }

            NamedChar {
                "char", ? "[]" : bool isArray, Identifier name
            }

            CharRange @internal {
                char rangeBegin,  ? "-" : char RangeEnd
            }

            RangeElement {
                "[", CharRange[] ranges, "]"
            }

            LookbehindElement {
                "?lb", "(", StringElement str, ")"
            }

            NotElement {
                "!", LexerElement ce
            }

        }

        NamedElement {
            Identifier type,  ? "[]" : bool isArray, Identifier name,
            ? bool isArray : ? ":" : StringElement lst_sep
        }

        ParenElement {
            "(", PatternElement[] elements : ",", ")"
        }

        FlagElement {
            "bool", Identifier flag_name
        }

        QueryElement {
            "?", "bool", Identifier flag_name, ":", PatternElement elem
        }

        OptionalElement {
            "?", LexerElement[] ce : ",", ":", PatternElement elem
        }

    }
}


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.

Cheers,
Bastiaan Veelo.