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.