Re: Writing an ODL parser?

Parse::RecDescent is not that hard to use. It also has that event triggering of callback functions quite nicely integrated.

For example you would define a table object:

tableobject : tablestart tabledef(s) tableend { tablefunc($item[1]) }

tablestart : 'OBJECT' '=' 'TABLE' "\n" { tablestartfunc() }

tabledef : columnnumber 
          | name 
          | bytes 
          | startbyte 
          | columnobject { columnstartfunc() }
          | rows 

columnnumber : 'COLUMN_NUMBER' '=' number /\n/ 
  { $return= recordcolumn($item{number});  }

number : /\d+/
[download]

In this example tablestartfunc() would be called at the start of a table definition, tablefunc() after the whole table was parsed, recordcolumn() would be called with the number of columns as parameter.

UPDATE:
Whether you record the table information with the callbacks or by using the $return mechanism of Parse::RecDescent is your decision. In the former case tablefunc doesn't need the $item[1] parameter and columnnumber() doesn't need to set $return. In the latter case columnnumber would need a more elaborate return value, for example $return= ['columnnumber',$item{number}];

Comment on Re: Writing an ODL parser? Select or Download Code

Replies are listed 'Best First'.
Re^2: Writing an ODL parser? by dHarry (Abbot) on Jul 30, 2008 at 14:04 UTC
Thanks for the example/explanation. I will spend some time on Parse::RecDescent to check if I can really use it. The example I gave was a bit simple, there are many different types of OBJECTS and the values can be a bit tricky (see my response to the post of moritz above.	[reply]
Re^3: Writing an ODL parser? by jethro (Monsignor) on Jul 30, 2008 at 18:56 UTC
That makes P::RD even better suited. The great advantage of P::RD is that you can and recursively (top-down or bottom-up) specify what is expected. So in your example you just define that keywordata is either a twodimsequence, a set or a text: `keywordata: twodimsequence \| set \| text` [download] How these are defined in detail you can work out later without the complexity of thinking about where they are used. Some time later you might define that a twodimsequence is a list of numberpairs surrounded by brackets: `twodimsequence: '(' numberpair(s) ')'` [download] You see, the definition of the language to parse is really easy and straightforward. The difficult part is mostly what to do with the parsed data. If you already know what your callback routines have to do, the only problems left are in the details. One detail is how to cope with the comments inside your data files. One idea (that might also help you with moritz and pc88mxer solutions) is to do the parsing in two phases. In the first phase you would delete all comments and fold data spread over multiple lines into one line, in the second phase you would to the parsing. Note that you can let more than one parser run over some text with P::RD, so it is well suited for that decoupling of problems The other possibility is to define the SKIP expression in P::RD to be sometimes not only spaces but comments and newlines as well. Or you just put 'comment(?)' or 'comment(s?)' in all places that a comment can be and define what a comment looks like (obviously no callback needed there). That may clutter your definitions but may be less tricky to get right than the SKIP method. The definition of a comment would probably look like this: `comment: m{/\* ([^]\|\[^/])* \*/ }x` [download] I don't say it is a walk in the park to get that parser running, the problems will be in the details. But you will be able to split the big problem into managable parts.	[reply] [d/l] [select]