sje wrote:In a flash of something other than brilliance, the coder got access to the school's Fortran compiler and modified the keyword table to accept all kinds of alternative spellings for the more troublesome keywords.
And this is what the PGN specification explicitly suggests to do. It is also what Bob has done in Crafty, as Crafty undoubtedly accepts "o-o" and "0-0".
The specification does that for good reasons, but it would be far better if it at least specified some minimum requirements such as "accept at least 0-0 and o-o in addition to O-O".
PGN wrote:Import format is somewhat more relaxed and it makes allowances for moves that do not conform exactly to the canonical format. However, these allowances may differ among different PGN reader programs.
As far as I can tell those "allowances" are as vague as can be:
There are a number of suggested guidelines for use with implementing PGN reader software for permitting non-canonical SAN move representation. The idea is to have a PGN reader apply various transformations to attempt to discover the move that is represented by non-canonical input. Some suggested transformations include: letter case remapping, capture indicator insertion, check indicator insertion, and checkmate indicator insertion.
You COMPLETELY miss the point. I don't recognize o-o and such because the standard suggests it. I do it because idiots refuse to follow the standard, and I would rather kludge up the PGN reading code as opposed to have to edit a many-zigabyte PGN file and fix every issue. I would greatly prefer to NOT have to handle crap, but until the idiots of the world actually comply with the standard, I do it for simplicity.
Steven't FORTRAN story is a good case in point. Not following the standard begets not following the standard. And the beat goes on...
syzygy wrote:No need for name calling towards your users...
No idea what you mean. If Crafty users save PGN files from within Crafty, they get something that matches the PGN standard for castling. I don't see how I would be talking about them. Someone that produces "broken PGN", even if many programs will accept it, is still an idiot. It is NOT hard to fix.
sje wrote:Suggesting, but never requiring, variant input was for the purpose of getting over a one time hump -- and that one time passed long ago.
Then I'm afraid you're not being very realistic.
In reality chess software accepts 0-0 and o-o, so there is no problem, but this is due to common sense of the programmers.
But if you think everyone who writes chess software MUST accept sloppy data, then there is a serious problem.
If the "standard" specifies what should be accepted, it is not sloppy. How difficult is that to understand. I can give you the ASCII codes for 0 and o, if you want.
Software engineering 101. Specifications should be clear, precise and not be ambiguous or use ambiguous terms. If you say (a) use O-O, and (b) accept 0-0, o-o, then your specification is ambiguous because you are saying both are OK.
I suppose one could add a footnote that says "legacy PGN files often use zero, big-oh and little-oh to indicate castling, and accepting those will prevent headaches when those are encountered. But the standard should be followed when producing NEW pgn data, period."
syzygy wrote:No need for name calling towards your users...
Aren't you the SAME person that argued against using undefined behavior even though it has worked for 30 years, because it violates the standard? But here it is not only ok, but the standard should indicate that it is ok to break it? IE apple broke strcpy() intentionally, for no good reason, and you thought that was OK. But here requiring programs to actually adhere to the standard is a bad thing?
