Questions

  1. Why did you choose the name 'Chaperon'?
  2. Should I use Chaperon if I want transform a simple text format into XML, e.g. CSV?
  3. Why did you start the project? Don't enough parsers exist already?
  4. Why does chaperon use XML as the format for a grammar?
  5. I miss xyz option in the regular expressions?
  6. Why aren't Kleene operator supported in productions?
  7. Why did you choose a push architecture instead of an pull architecture?
  8. Why did you make such a strict separation between the automaton and the processor?

Answers

1. Why did you choose the name 'Chaperon'?

The parser works really exact? And if I ever thought the parser didn't work correct, I was wrong.

2. Should I use Chaperon if I want transform a simple text format into XML, e.g. CSV?

Chaperon isn't always the best solution. But I think the fact that you don't have to write code is very useful.

3. Why did you start the project? Don't enough parsers exist already?

I had three intentions in writing this new parser. First, I wanted to have a parser with XML as an input and output format. Second, most of the parsers mixed content and code in their grammar files. I wanted a parser that followed the SoC(Separation of Concerns). The grammar doesn't have anything to do with the final output format or actions. Third, I used this project as an exercise in programming parsers.

4. Why does chaperon use XML as the format for a grammar?

So Chaperon doesn't need a parser to parse its own grammar file. And it's simple to convert a text grammar to a Chaperon grammar with an XSLT stylesheet. It the old question: which comes first, then chicken or the egg? It is also easier to transform a different grammar format with XML.

5. I miss xyz option in the regular expressions?

The matcher of the lexer is designed to work as fast as possible. So some options that modern matchers support weren't implemented (like lookaheads).

6. Why aren't Kleene operator supported in productions?

The parser generator doesn't depend on this possibility. I think it's a better way to transform a complex grammar to simpler format by an external process.

7. Why did you choose a push architecture instead of an pull architecture?

I think there isn't really a difference between the two. The scanner is more design to work in a push architecture and the parser is more design to work in a pull architecture. And to be compatible with the SAX enviroment I choose the push architecture.

8. Why did you make such a strict separation between the automaton and the processor?

The reason was that I want two components: one component holds the state in the parsing process and the other component holds the logic and is completely threadsafe. The automaton can have a huge among of memory, but is threadsafe, so I needed only one instance. And the processor can use only one parsing process, but it's cheap in its memory use.