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

[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 to concern one aspect or another of the
layout engine not the parser.

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

[dhudes]

> On Mon, Mar 21, 2011 at 4:04 PM,  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 -very- useful. I've never used your module but I have
implemented FSM though it has been quite some time since I tried to
describe one mathematically. A parser has states it is certainly true but
is not quite the same thing.
>

> Yes, yes!  Perhaps Shlomi will explain exactly what the itch is that he's
> scratching? I'm just guessing: does the existing Graph::Easy have issues
> with mixed-direction unicode?

That's a lexer issue not a parser issue.  Parsers deal with symbols which
are the output of the lexer.  Switching from left->right to right->left
word order is certainly an odd thing to do but in the end a parser deals
with a sequence of symbols.

>
>
> --
> simple interpolable credential obfuscator:
> perl -ple 's/(.)/sprintf "\\%03o",ord $1/ge;'
>

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

[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
> > Graph::Easy::StateMachine
> > ,
> > for a future Graph::Easy that is self-hosting. How cool would that be or
> > what?
> >
> 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.
> 
> The thing about parsing and Perl is that your lexer can be based on
> regular expressions which Perl of course understands itself. Regardless,
> the first step is to come up with a formal grammar. The RHS of the
> productions are calls to Graph::Easy.
> 
> At this time, we have a working parser for Graph::Easy regardless of how
> it was created. While a formal grammar is wonderful for documenting that
> language, why are we looking at replacing the parser in the first place?
> what size /complexity input is causing such a performance problem?

Best to start reading here, about maintenance. Nothing was said (in this
thread?) about performance.

http://community.livejournal.com/shlomif_tech/57021.html

> Or is that new features for the language are desired and it is difficult
> to implement them in the existing system?

It's not new 'features', it's new 'humans', to do the
support/maintenance.


-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

Re: The future of Graph::Easy

[Ron Savage]

Hi Tels

I'm copying others in this reply.

On Mon, 2011-03-21 at 16:10 -0400, Tels wrote:
> Sorry,
> 
> I only got a few emails which are probably not in order, so I haven't read
> everything. But I'll reply anyway :)
> 
> On Sat, March 19, 2011 7:16 pm, Ron Savage wrote:
> > Hi Shlomi
> >
> > Let me say things in different words.
> >
> > Our primary goal is ensuring the future of the module, right?
> >
> > To me, this implies any of these items /might/ be jettisoned:
> >
> > o Pure-Perl
> 
> This would be only a choice of speed (e.g. you could have a transparent XS
> module, or C::Inline). However, when Pure-Perl works, why throw it away?

Shlomi Fish describes his position here, together with my (initial)
reply:

http://community.livejournal.com/shlomif_tech/57021.html


> > o Current parser
> 
> The parser might not be the best, but what exactly are your problems with it?

Maintenance.

> > o Current input format
> 
> If you throw away the Graph::Easy input format, you will have killed the
> module's spirit. The *entire* point of Graph::Easy is the
> easy-to-write-easy-to-read input format. Everything else is just to keep
> it being useful.

Understood. The aim is to support some simple syntax, but (from my point
of view) not necessarily the current syntax.

> > So, I'd like the discussion to focus on choosing the best tools to
> > support the module.
> >
> > Thus, I'm saying the current input format, e.g., is not driving the
> > discussion, but rather the search for tools is.
> >
> > That in turn means that if a different parser is chosen, then changing
> > the input format would be a consequence (i.e. not a driver) of that
> > choice.
> 
> Why then not write your very own module, where you have the choice of your
> own format, own parser and own language? I mean, you might as well use
> graphviz, it is written in C, has a different parser AND a different input
> format?

Good point.

And if that were to happen, I for one would certainly want to maintain
the great spirit of Graph::Easy's design.

> Sorry, but I don't understand the force behind this at all.
> 
> all the best,
> 
> tels
> 
> 

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

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

[David Nicol]

On Mon, Mar 21, 2011 at 4:04 PM,  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 parsing and Perl is that your lexer can be based on
> regular expressions which Perl of course understands itself. Regardless,
> the first step is to come up with a formal grammar. The RHS of the
> productions are calls to Graph::Easy.
>

Regular expressions describe state machines, for instance. Regex is a
descriptive (opposed to procedural) language. So is Graph::Easy.

At this time, we have a working parser for Graph::Easy regardless of how
> it was created. While a formal grammar is wonderful for documenting that
> language, why are we looking at replacing the parser in the first place?
> what size /complexity input is causing such a performance problem?
> Or is that new features for the language are desired and it is difficult
> to implement them in the existing system?
>

Yes, yes!  Perhaps Shlomi will explain exactly what the itch is that he's
scratching? I'm just guessing: does the existing Graph::Easy have issues
with mixed-direction unicode?


-- 
simple interpolable credential obfuscator:
perl -ple 's/(.)/sprintf "\\%03o",ord $1/ge;'

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

[dhudes]

>
> 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
> Graph::Easy::StateMachine
> ,
> for a future Graph::Easy that is self-hosting. How cool would that be or
> what?
>
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.

The thing about parsing and Perl is that your lexer can be based on
regular expressions which Perl of course understands itself. Regardless,
the first step is to come up with a formal grammar. The RHS of the
productions are calls to Graph::Easy.

At this time, we have a working parser for Graph::Easy regardless of how
it was created. While a formal grammar is wonderful for documenting that
language, why are we looking at replacing the parser in the first place?
what size /complexity input is causing such a performance problem?
Or is that new features for the language are desired and it is difficult
to implement them in the existing system?

One possible future of parsing Graph::Easy input texts

[David Nicol]

On Sun, Mar 20, 2011 at 6:42 PM,  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
> - any of several Perl implementations including Parse::Yapp / Parse::Eyapp
> - using bison to generate a parser in C and then gluing that in with XS or
> even Inline::C




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 
Graph::Easy::StateMachine
,
for a future Graph::Easy that is self-hosting. How cool would that be or
what?


-- 
"This is not a 'bug'. Being documented, it is merely a 'restriction'." --
Intercal manual