Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » KiCAD
  • » [Kicad-developers] Proposed Recursive Descent s-expression Parser Design Pattern [RSS Feed]

#1 Jan. 18, 2011 15:12:01

Dick H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] Proposed Recursive Descent s-expression Parser Design Pattern


I am proposing the following design pattern for the PARSER and LEXER used
with the TokenList2DsnLexerl.cmake technology. This is a change I am
volunteering to make, but wanted to see if anyone had any objections or
improvements first.




New Design Pattern:
==================

Let:

class <object> = is a non-trivial container class

class <object>_PARSER = the parser class for class <object>.



1) Parsing is done in a separate class for each major <object>, derived from
the corresponding lexer class. <object>_PARSER is to be derived from
<object>_LEXER. The <object>_PARSER class may be a friend of the <object>
being stuffed. <object>_PARSER can also handle the parsing for any
*trivial* object contained within <object> which does not have its own PARSER.


3) class <object>_PARSER be given a function :

public:
void <object>_PARSER::Parse( <object> * aObjectToBeStuffed ) throws(
IO_ERROR, PARSE_ERROR )


2) class <object> be given a function :

public:
void <object>::Parse( <object>_PARSER* aParser ) throws( IO_ERROR, PARSE_ERROR )

which is always implemented as just this:

{
aParser->Parse( this );
}


3) Every <object>_PARSER class is to have at least this one constructor:

<object>_PARSER( LINE_READER* aReader )

// allows sharing of aReader.


4) Every <object>_PARSER be given the method:

LINE_READER* <object>_PARSER::GetReader();


There are only minor changes needed to transition to this design pattern, we
are almost there already.


The Benefits:
==============

*) The token enums for the keywords can then be moved into the base
<object>_LEXER classes and we don't need enum namespaces. What makes this
possible is that the PARSER can access the enum from its *base* class, the
<object>_LEXER, without having to use any special enum prefix, although it
may need to use a "using" directive.

*) Simplifies the construction of the LEXER and PARSER combination, can be
done in fewer inline lines of code. (The new PARSER<->LEXER constructor
linkages take care of this simplification in a standard way.)

*) Keeps involved parsing code out of the <object> class, and out of its
header file. <object>_PARSER will have many functions/methods, probably one
for each trivial nested object. So keeping these out of public view is
valuable for reduced compile time, etc.


*) Allows falling down easy chaining of <object>_PARSERs when a major object
contains another major object which also has its own PARSER class, because
the LINE_READER* can be lent to the nested object's PARSER.


I would probably start by putting the big specctra parsing code under this
model as a "does it hold water" test. This change can be done in less than
40 changed lines of code I think.


Feedback welcomed,

Dick


_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

  • Root
  • » KiCAD
  • » [Kicad-developers] Proposed Recursive Descent s-expression Parser Design Pattern [RSS Feed]

Board footer

Moderator control

Enjoy the 17th of August
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support