bug-xboard
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-XBoard] [bug #27799] fix for nested-nested-nested variations


From: anonymous
Subject: [Bug-XBoard] [bug #27799] fix for nested-nested-nested variations
Date: Wed, 28 Oct 2009 11:13:00 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Follow-up Comment #10, bug #27799 (project xboard):

OK, problem here is that the parser recognizes several types of "comments",
between {} or (). XBoard then strips off the delimiters, appends all comments
belonging to the same move to each other, and saves between {}. This loses the
(), and explains why there is no closing brace after "opponent.". This in
itself is not responsible for the error, as there also is no opening "("
before "15. e4", and the matching closing ")" has been replaced by "}". This
of course f*s the syntax of sub-variation nesting, but hey, it is only a
comment.

But the effect of this is that the comment within the subvariation "{has been
the main choice..." is now no longer 'protected' by the subvariation's () that
were around it in the original file. So the saved file has a _nested_ comment
"{{}}". And it turns out the parser choked on that, as its rule for parsing
comments is:

{[^}]*} {                               /* anything in {} */

i.e. it triggers on the first closing brace, no matter how amny opening
braces it encounters. So we drop out of comment mode too quickly, and start
parsing moves in the sub-variation like they were game moves.

The problem disappears when I add the rule:

{[^{}]*({[^{}]*}[^{}]*)+[^{}]*}  { /* nested {} */

What does the PGN stndard say here? Do {} have to be balanced?. For safety I
left the old rule after the new one, so that when no balancing }} is found,
parsing resumes after the first } that is found.

Of course what we are trying to do here is doomed from the outset. A state
machine like lex is fundamentally incapable to parse a recursive language as
required for describing balanced  parenthesising. Nesting is bad enough, but
the use of both () and {} turns it into a disaster. We can add all the
patterns for mixed nesting of {}, () (and []?) we want, but it will always be
possible to design a PGN that has more levels of nesting than our deepest
pattern has. And then I am still only addressing parsing of correctly balanced
PGN.

H.G. Muller

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27799>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]