Re: [Bug-gnubg] compile error

[Jim Segrave]

On Wed 27 Oct 2004 (07:24 +1300), Joseph Heled wrote:
> 
> 
> Achim Mueller wrote:
> >* Jim Segrave wrote on 26 Okt 2004:
> >
> >
> >>>Yep, it compiles now without errors, but I still have the "illegal
> >>>character" problem when opening older analysed matches.
> >>>
> >>>Ciao
> >>>
> >>>Achim
> >>
> >>Can you send me such a match? 
> >
> >
> >I'm sorry, but I'm an idiot ;-). 
> 
> We have no doubt about that :)
> Seriously, this is just sub-par handling of error detection. I think we 
> spoke about automatic detection of file formats before, either from file 
> extension, file contents, or both.
> Does anyone remember what happened to that? Or is my memory wrong?

The truth is that I think most of the file importing code is sort of
sub-optimal. What I think should be happening is that we start with
BNF for the various formats and write parsers, probably recursive
descent ones, that build a canonical game representation and only if
that succeeds do we go from there to gnubg's internal match
reprsentation.

Advantages:

1) On error, you can always simply indicate where in the file you were
   - line no and charcter no, game and move reached to this
   point. After which you simply discard everything. You don't have to
   unwind any of gnubg's internal match representation.

2) a canonical intermediate form keeps the internal representation and
   the parsing code well separated. There are known, and often
   discussed, limitations with the current internal representation. If
   we wanted to change it today, we'd have major work to do on not
   only the playing and anlysis code, but also on all the import and
   export routines. 

3) the canonical form might be a good developing ground for improving
   the internal format

4) if the canonical form were to be something like an xml parse tree,
   then we'd be very close to being able to create an xml format for
   import/export of games. I once started sketching out such a format,
   but stopped when I decided my knowledge of using xml properly was
   insufficient. While xml is in principal very simple, effective xml
   design seems less so to me at least. 

Disadvantages:

1) It's a lot of work
2) It's not clear that all of the formats are well understood nor that
   they have unambiguous grammars.I think .sgf files do, but I'm not
   so sure about .mat files or some of the other import formats.

-- 
Jim Segrave           address@hidden