0

What is the correct grammar to parse a move in SAN format using PEG?

The solution I come up is 

MOVE <- [NBRQK]? [a-h]? [1-8]? [-x]? [a-h] [1-8] [NBRQ]?

However, this seems wrong as it doesn't parse Nh4 because h matches the first optional file [a-h]? and the parser doesn't backtrack.

Other moves that should be correctly parsed are: a4, a3a4, xa4, a8Q, xa8Q, Nh4, Nxh4, Ngxh4, Ng3h4,Ngh4, N3h4, Ng3-h4, Ng3xh4, but (optionally) not -a4, N-h4.

Alexandru
  • 25,070
  • 18
  • 69
  • 78

1 Answers1

-2

I've built algebraic notation parsers before.

Frankly, the grammar is pretty simple (as you show, didn't check details).

More importantly, I don't recall any need to backtrack, which is the point of using PEG. So you don't need a mechanism this complex.

In fact, "parsing" this is so simple that building a real parser seems like overkill; you can build an FSA to recognize it without much trouble.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
  • I have an EPD parser. Move parsing is just one small part of it. – Alexandru Aug 01 '16 at 09:29
  • You may have other troubles, but your question related only to parsing moves. – Ira Baxter Aug 01 '16 at 13:13
  • The question is related to move parsing using *PEG*. I have a simpler grammar for move parsing implemented manually. PEG is important because the rest of my grammars are in PEG and I need proper integration. – Alexandru Aug 23 '17 at 10:06
  • Your problem is your grammar is too simple. It hasn't anything to do with PEG or backtracking. I'm not going to write your grammar for you. – Ira Baxter Aug 24 '17 at 10:23