On Sun, Jun 14, 2015 at 10:47 AM, Keean Schupke <[email protected]> wrote: > > data Program = Prog [Declaration] > data Declaration = Decl Variable Expression > data Variable = Var String > data Expression = Apply Expression Expression | Abstract Variable Expression > | Variable > > Taking the above program abstract syntax, it seems obvious to me that > parsers should output these elements. > > For example if we have the following syntax for an abstraction: > > '\', {space}, var, {space}, '.', {space}, expression > > This clearly relates to the "Abstract Variable Expression" value > constructor. > > This might be in combinators: > > auto const lam_tok = tokenize(accept(is_char('\\'))); > auto const var_tok = tokenize(accept(is_alpha) && many(accept(is_alnum))); > auto const dot_tok = tokenize(accept(is_char('.'))); > > auto const abs = all(return_abs, discard(lam_tok) && var_tok, > discard(dot_tok) && expr); > > So to integrate this with the abstract syntax, we need to assert that: > > typename abs::value_type > > Is "Abstract Variable Expression" from the AST. > > So I would consider the AST itself determines the grammar,
No. If you had chosen a different surface syntax for lambda abstraction, you'd need a different parser too, but the AST hasn't changed. What I think you're pointing out is that in practice the AST structure will lead to a sensible grammar. But clearly the grammar is not uniquely determined by the AST structure. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
