rns tag:blogs.perl.org,2009-11-03:/users/rns//933 2012-11-09T14:30:36Z Confessions of a Marpa Toolsmith Movable Type Pro 4.38 Windows port of Marpa::R2 tag:blogs.perl.org,2012:/users/rns//933.4033 2012-11-09T14:24:41Z 2012-11-09T14:30:36Z A very good thing indeed. Can't wait to get my hand on it.... rns https://github.com/rns A very good thing indeed. Can't wait to get my hand on it.

]]> A Parser for Marpa::R2 tag:blogs.perl.org,2012:/users/rns//933.4032 2012-11-09T11:44:23Z 2012-11-09T14:40:32Z This proof-of-concept (test, module) parser takes input, invokes lexer as needed, evaluates parse tree(s) and returns the value.... rns https://github.com/rns This proof-of-concept (test, module) parser takes input, invokes lexer as needed, evaluates parse tree(s) and returns the value.

]]> The goals include (0) to enable automagic invoking of the lexer and alternate()/end_input() for ambiguous tokens, (1) to hide the recognizer set up and parse tree(s) evaluation while keeping the ability to customize Marpa::R2::Recognizer with named arguments, (2) to provide a method for arbitrary parse tree construction and (3) to facilitate specific methods of lexing the input and read()ing the tokens for specific applications, e.g., natural language parsing (NLP).

P.S. This behavior is provided by passing default_action to the parser that will be set to the grammar and used to determine the type (if known) and thus construct the parse tree or anything that default_action is set about to.

]]> Algebra of Grammars? tag:blogs.perl.org,2012:/users/rns//933.4031 2012-11-09T10:52:52Z 2012-11-09T11:32:02Z As in "I can parse integers and F can parse floats so I + F must parse integers and floats". Not sure what I *F must do though. :) Akin to parser combinators, perhaps. Executable notation with Marpa just as... rns https://github.com/rns As in "I can parse integers and F can parse floats so I + F must parse integers and floats".

Not sure what I *F must do though. :)

Akin to parser combinators, perhaps.

Executable notation with Marpa just as the relational algebra is executable with SQL.

Looks like an algebra of grammars be defined in terms of their parseable sets (Algebra of Sets). Then I *F must parse only integers (intersection).

And then, if a problem domain can be reduced to an algebra of parseable entities, it must be parsed by an algebra of grammars with all benefits of mixing, matching, and reusing grammars at will.

That's all probably looks too trivial or too vague, but it starts making much more sense (to me at least) when doing general practical BNF parsing with Marpa::R2 now that grammars like this see the light of day.

]]> A Lexer for Marpa::R2 tag:blogs.perl.org,2012:/users/rns//933.4030 2012-11-09T10:02:47Z 2012-11-09T10:49:44Z This proof-of-concept lexer (module, test) extracts literals (and other terminals) from a Marpa::R2::Grammar and turns them to regexes to tokenize string input for Marpa::R2::Recognizer.... rns https://github.com/rns This proof-of-concept lexer (module, test) extracts literals (and other terminals) from a Marpa::R2::Grammar and turns them to regexes to tokenize string input for Marpa::R2::Recognizer.

]]>

It is made possible by check_terminal(), rule_ids(), and rule() accessors provided by Marpa::R2::Grammar.

It works because token names to be read() by Marpa::R2::Recognizer must be terminal symbols of Marpa::R2::Grammar.

A literal (and terminal, in some cases) fits the definition of a token perfectly, so tokenizing input by (pre-)splitting on literals (terminals) looks obvious, but I was unable to find definitive links and so feel a bit uneasy as to whether or not this would work in general.

But more testing will show the truth, I think. :)

]]>