One possible future of parsing Graph::Easy input texts

2011-03-21 Thread David Nicol
On Sun, Mar 20, 2011 at 6:42 PM, dhu...@hudes.org wrote: In terms of considering parser improvements or reimplementation, the first step is to come up with a formal grammar for the language. Preferably a Context Free Grammar (CFG) expressed in BNF or EBNF. Once we have that we have options -

Re: One possible future of parsing Graph::Easy input texts

2011-03-21 Thread David Nicol
On Mon, Mar 21, 2011 at 4:04 PM, dhu...@hudes.org wrote: An interesting concept but describing the syntax as a grammar is not the same as an FSA. The FSA is part of the parser and lexer. I disagree. State Machine is a powerful abstraction that is useful in many places. The thing about

Re: One possible future of parsing Graph::Easy input texts

2011-03-21 Thread Ron Savage
Hi On Mon, 2011-03-21 at 14:04 -0700, dhu...@hudes.org wrote: One could describe the Graph::Easy format grammar as a state machine, draw the state machine with Graph::Easy, then implement a parser from your diagram, with

Re: One possible future of parsing Graph::Easy input texts

2011-03-21 Thread dhudes
On Mon, Mar 21, 2011 at 4:04 PM, dhu...@hudes.org wrote: An interesting concept but describing the syntax as a grammar is not the same as an FSA. The FSA is part of the parser and lexer. I disagree. State Machine is a powerful abstraction that is useful in many places. FSA/FSM are

Re: One possible future of parsing Graph::Easy input texts

2011-03-21 Thread dhudes
I reviewed the list of bugs at https://rt.cpan.org/Public/Dist/Display.html?Name=Graph-Easy Very few seem related to parsing or the input language. The layouter hanging on a 749 edge graph would seem a problem even if you explicitly did it with calls from perl code. Indeed most of the bugs seem