19-NOV-2024

2313 - pgn

I’m frustrated by the fact that PGN requires, essentially, an entire movegen system to parse. I’m going to hack in something in the ‘good enough’ category so I can flesh out the Variation stuff and then probably put it down and go to work on the MoveGen. I have an idea for it that I think will work well with the design I’m aiming for. In a surprise to no one, it’s copying the Alter system. I’m going to use the old movegen as a guide, and focus on building a system that can implement a rich language for querying a boardstate. I can then use this to build a movegen system that is abstract with respect to boardstate and can abstractly describe different movegen calculation strategies that can then be run against multiple backend boards.

An implementor would then have to implement some minimal set of operations, which all others must be expressed in terms of, and then I can build different backend representations designed to make some operations faster.

Ultimately this will build up to a general language that can describe how to arrive at specific boardstates, and how to do analysis downstream.

You’d have a script that describes some algorithm to tell the engine how to proceed from it’s current position, what to evaluate (e.g., maybe “find the top 100 lines from this position for white at depth n and then calculate the relative power of the black bishop in each lines and report the distribution as a graph”), and then hazel would haul off and do the work.

Each little language is really a part of this bigger language that ultimately ‘compiles’ to some glue language.

I was hoping to get pgns more fully and comfortably supported, but I don’t think that’s going to be possible right now. I might still work on the Variation -> PGN (at least the mainline) so I can display it in the UI, but I’ll have to think about how much I want to keep writing parser/printer code.