SAN parser within a PGN parser

[mathmoi]

Hi,

I'm currently writing a PGN Parser in C, I'll eventually release it as open source in case anyone would like to use it in their own engine/applications.

At the current stage, the parser is able to parse complex PGN files and separate all the items of the move text (move, comments, annotations and variations), but it doesn't know nothing about chess. This means that it can provide the user with a list of moves in text format, but it can't check if they are valid or can't separate them in piece/from/to/piece taken/promotion components.

I'm not sure if I should provide the functionality to parse the SAN moves within my PGN Parser. If I do it, I'll need to include a complete "move generator stack" (board struct, make()/unmake(), movegen(), etc.). This have some drawbacks. First of all it adds lots of complexity to an otherwise simple parser. Secondly, if someone wants to use this in it's own chess engine or application it probably already have a "move generator stack" and possibly it's own SAN parsing code.

On the other hand, if the parser does not handle the SAN move parsing it will be less useful to some peoples.

I'm not sure yet if I should include a SAN Parser in my PGN parser. What do you guys think?

[ZirconiumX]

Hi,

I'm currently writing a PGN Parser in C, I'll eventually release it as open source in case anyone would like to use it in their own engine/applications.

At the current stage, the parser is able to parse complex PGN files and separate all the items of the move text (move, comments, annotations and variations), but it doesn't know nothing about chess. This means that it can provide the user with a list of moves in text format, but it can't check if they are valid or can't separate them in piece/from/to/piece taken/promotion components.

I'm not sure if I should provide the functionality to parse the SAN moves within my PGN Parser. If I do it, I'll need to include a complete "move generator stack" (board struct, make()/unmake(), movegen(), etc.). This have some drawbacks. First of all it adds lots of complexity to an otherwise simple parser. Secondly, if someone wants to use this in it's own chess engine or application it probably already have a "move generator stack" and possibly it's own SAN parsing code.

On the other hand, if the parser does not handle the SAN move parsing it will be less useful to some peoples.

I'm not sure yet if I should include a SAN Parser in my PGN parser. What do you guys think?

As you said, the engine

possibly

has its own SAN code.

I would recommend having the code in, if only so you can translate to LAN.

Matthew:out

[mathmoi]

As you said, the engine

possibly

has its own SAN code.

I would recommend having the code in, if only so you can translate to LAN.

I had not tough about that, but you are right. Some engines will not be able to parse SAN moves at all even if they have a move generator.

I hate to have to provide a full board/move generator just to parse the moves, but I might not have a choice if I want my parser to be useful.

[Don]

As you said, the engine

possibly

has its own SAN code.

I would recommend having the code in, if only so you can translate to LAN.

I had not tough about that, but you are right. Some engines will not be able to parse SAN moves at all even if they have a move generator.

I hate to have to provide a full board/move generator just to parse the moves, but I might not have a choice if I want my parser to be useful.

There should be no problem with that if the code is small and compact.