The ++ and +-+ date from before the PGN standard and were there just to deal with some of the many variations of chess notation that you'd find in hand-typed usenet posts, etc. I don't think anyone will notice if you remove support for them.
On Tue, Nov 2, 2010 at 8:37 AM, h.g. muller <[email protected]> wrote: > How important is it to retain the possibility to parse "++" > (White/BlackWins) and "+-+" (GameIsDrawn)? > > I have a terrible problem there: Normally a "+" suffix on a move indicates > check, but in Shogi it indicates a promotion. To reliably reognize > promotions in Shogi I thus had to add the "+" suffix to the rules for moves. > But the consequence of this is that the first "+" after a move is always > eaten away, which is usually OK, as check indicators were ignored anyway. > But when a mve is followed by "++" or "+-+", the rules for that no longer > get to see the first "+", so they see just "+" or "-+". I could add a rule > that parses the latter to GamesDrawn, but the solitary "+" is a problem. The > current state is that the parsing of these symbols is broken. > > The only way I see to get it back is very cumbersome: let the parser, in > the rule for each move, set a global flag if it pased a "+" with the move, > and make rules "+" and "-+" that return new symbols. Then make a wrapper for > yylex(), which, on encountering these symbols, checks if the "+" flag was > set, and if so, turns them into White/BlackWins or GameIsDrawn before > returning them (and if not, just igore them). And before returning anything > that is not some kind of move, clears the "+" flag. Is this really worth it? > I thought that the compliant way to incicate checkmate is # or 1-0 or 0-1. > > Of course the up-side of a wrapper around yylex() is that we could also > make rules and smbols for "(" and ")", and let the wrapper take care of > nesting to arbitrary depth. > >
