Loading ...
Sorry, an error occurred while loading the content.

Extra Parens Well-Formed?

Expand Messages
  • ashleyfeniello
    Just to be certain, extra parenthesis are still well-formed SGF? For example: (;N[A](;N[B](;N[C](;N[D]))(;N[E]))) is the same tree as:
    Message 1 of 2 , Jun 26, 2002
    • 0 Attachment
      Just to be certain, extra parenthesis are still 'well-formed' SGF?
      For example:

      (;N[A](;N[B](;N[C](;N[D]))(;N[E])))

      is the same tree as:

      (;N[A];N[B](;N[C];N[D])(;N[E]))

      and should be handled correctly by all parsers?

      --

      Not that it could possibly be changed at this point, but I'm curious:
      Why the use of semicolons in addition to parenthesis. In the latter,
      we save parenthesis; one for each non-branched node, but have
      unnecessary semicolons on branched nodes. In the former case all of
      the semicolons are excessive. Why not:

      (N[A](N[B](N[C](N[D]))(N[E])))

      .. which in this particular case is the shortest representation. For
      non-branching game records the standard way is best. Is this savings
      the reasoning?

      The difficulty comes when trying to output SGF without requiring
      foreknowledge of whether a particular node has siblings. That is,
      with methods like WriteNodeStart(), WriteProperty(), …,
      WriteNodeEnd
      () where start A, start B, end B, end A implies that B is a child of
      A. This is how I'm used to dealing with XML serialization.

      Trying to maintain the simplified SGF in a forward-only writer
      requires buffering until either a close or a sibling is seen.
      Whereas the non-simplified version can be spewed to the underlying
      stream immediately.
    • Arno Hollosi
      Ashley, sorry for the delay in answering. ... Correct. It does not matter that a branch does not have any siblings. ... I guess this comes from the EBNF
      Message 2 of 2 , Jul 6, 2002
      • 0 Attachment
        Ashley,

        sorry for the delay in answering.

        > Just to be certain, extra parenthesis are still 'well-formed' SGF?
        > (;N[A](;N[B](;N[C](;N[D]))(;N[E])))
        > is the same tree as:
        > (;N[A];N[B](;N[C];N[D])(;N[E]))
        > and should be handled correctly by all parsers?

        Correct. It does not matter that a branch does not have any siblings.

        > Not that it could possibly be changed at this point, but I'm curious:
        > Why the use of semicolons in addition to parenthesis.

        I guess this comes from the EBNF definition:

        Collection = GameTree { GameTree }
        GameTree = "(" Sequence { GameTree } ")"
        Sequence = Node { Node }
        Node = ";" { Property }

        > In the former case all of the semicolons are excessive.
        > Why not: (N[A](N[B](N[C](N[D]))(N[E])))

        Because in a game of 250 moves you would have to add 250 closing parenthesis
        at the end.

        > For non-branching game records the standard way is best. Is this savings
        > the reasoning?

        I think so. Furthermore, non-branching games are the majority of all
        game-records. Even the records of the Go Teaching Ladder contain only about 5
        branches on average.

        > The difficulty comes when trying to output SGF without requiring
        > foreknowledge of whether a particular node has siblings.

        Is that foreknowledge not always present? Don't all SGF programs have some
        internal tree structure in which they hold moves (aka XML-DOM model)? If your
        program has an internal tree-structure writing SGF is easy:

        WriteTree(Root)
        End

        WriteTree(Node)
        Write(Node)
        for each child of Node
        WriteTree(child)
        end for
        end

        In case of SGF filters (aka XML-SAX model) that don't add new branches just
        keep the paranthesis, even if they become superfluous afterwards. It doesn't
        heart the parsers.

        /Arno
      Your message has been successfully submitted and would be delivered to recipients shortly.