Thanks Diego! I really appreciate your comments. Best regards. Arturo
On Fri, Feb 2, 2018 at 6:27 AM, Diego Lont <diego.l...@delware.nl> wrote: > Hi, > > I have never used dependents (^ (self dependencyAt: StatementBParser) > ruleB), but here are my thoughts when reading this. > > When parsing it makes sense to make a separation between syntax and > semantics. Applying this functional distinction in your technical design > usually makes sense. In practical terms making a class for the syntax (i.e. > StatementASyntax) and one class for the semantics, subclassing the syntax > (i.e. StatementASyntax subclass: StatementAParse). > > So the question here is what class is responsible for the semantics and > what class is responsible for the syntax. Depending on the answer on this > question you should build your tree. Do you want your statement parsers to > know the semantics of the statements as well, then I would suggest separate > these in a syntax and a parser (and only having production rules in > PLParser for rules that combine things and no production rules when the > rule is merely forward them to your statement parser). > > Or do the statement parsers merely do the syntax, and does the PLParser > apply the semantics (maybe because the semantics is context sensitive), the > you should not create a duplicate structure in your statement parsers, but > have the production rules i the PLParser (or a subclass of PLParser). > > As to your maintenance nightmare: > - I would add a superclass for the syntax, and not a subclass for the > semantics. > - And maybe you should consider referring to the parser as a resource / > factory method, so you only have one reference to each of your statement > parsers. > > PLParser>> ruleB > ^ (self dependencyAt: self statementBParser) ruleB > > PLParser>> statementBParser > ^ StatementBParser > > Regards, > Diego > > > > On 01 Feb 2018, at 14:42, Arturo Zambrano <arturo.zambr...@gmail.com> > wrote: > > > > Hi All, > > Could you please share some advice on the following situation? > > I wrote my first Petit Parser. > > From the documentation I read that: > > 1) it is possible to depend on other parsers making the development more > modular. > > 2) The docs also suggest that, in order to separate grammars rules from > productions, we can make a parser with productions a subclass of a parser > which defines the grammar. > > > > I started applying 1) so my structure is something like > > > > AbstractParser " contains some common basic elements common to all > subclasses) > > StatementAParser > > StatementBParser > > PLParser "this guy uses the StatementX parsers" > > > > So there is a parser for different statements of the programming > language. > > The PLParser uses PetitParser dependency mechanism to rely on the > Statement*Parsers. For instance: > > PLParser>> ruleB > > ^ (self dependencyAt: StatementBParser) ruleB > > > > > > So far so good, the grammar is working, the parser works. > > > > Now, I would like to write the productions, separately from the grammar > part (remember 2) ), so I should make subclasses adding the productions in > the form > > >>ruleA > > ^super ruleA ===> [ my production code] > > > > The point is that PLParser explicitly depends on Statements*Parser, and > the name of the Statement*Parser appears here and there, so creating > subclasses would result in maintenance nightmare. The new layer of parsers > with productions will duplicate the dependencies and I foresee it will be a > mess. > > > > So now, I think that having just one big class with all the rules for > the grammar is better if you plan to separate productions code isolated > from the grammar. > > > > Am I right? Maybe I'm missing some point regarding writing composed > parsers and separating productions from grammar. > > > > Any pointer or comment is welcome. > > > > Arturo > > > > >
