Expose the `QuadBitboard` type

[deepfire]

It would be nice to have QuadBitboard exposed -- while it only represents game state partially, it is still useful:

• contains exactly enough information to render the chessboard
• has a very efficient representation -- for serialisation and network exchange

Currently building a type-safe API on top of chessIO, based on session types -- but as it stands I have to inline the relevant modules, instead of importing the library..

[mlang]

Kosyrev Serge ***@***.***> writes:

It would be nice to have QuadBitboard exposed -- while it only represents the partial game state, it is still useful: * it contains exactly enough information to render the chessboard

Why not use pieceAt?

* it is has a very efficient representation -- for serialisation and network exchange

FEN is roughly the same size as a qbb, and it is standarized. Sounds like a far better option for serialisation and network transport. Hiding the qbb is actually on purpose, since there are several ways to represent a position as a qbb. I'd like to keep my hands untied for future changes. Especially if GHC ever adds xor of 4x64 vectors, which would finally allow to use SIMD for qbb. Another thing I'd like to try one day is to change the "black" bitboard to an "us" bitboard, and implement a rotate function which turns the board around. This approach allows for simpler move generation, since we suddenly only have to care for one side, namely, "us", independent from what color is about to move.

…

-- CYa, ⡍⠁⠗⠊⠕

[deepfire]

Kosyrev Serge @.***> writes:

It would be nice to have QuadBitboard exposed -- while it only represents the partial game state, it is still useful:

• it contains exactly enough information to render the chessboard

Why not use pieceAt?

The "server" side that enforces rules keeps the Position as internal state.

As the game state evolves, it sends the current board state (but not the entire game state) to the "players" side -- and if I can send the internal QuadBitboard, that requires merely handing out the value, without modifications.

If i have to transform it, by querying the entire board with pieceAt -- that's an awful lot of extra computation.

• it is has a very efficient representation -- for serialisation and network exchange

FEN is roughly the same size as a qbb, and it is standarized.

That's a fair point, and indeed length $ toFEN startpos yields a mere 56 bytes.

My problem with that is that instead of just shovelling the 4 64bit words over the API boundary (and yes, I get the point about API stability), I now have to commit to executing toFEN at each such point, which is not exactly free.

However in my case the API stability is much less of a concern, since I control both sides, and so the interpretation of QuadBitboard.

Sounds like a far better option for serialisation and network transport. Hiding the qbb is actually on purpose, since there are
several ways to represent a position as a qbb. I'd like to keep my hands untied for future changes. Especially if GHC ever adds
xor of 4x64 vectors, which would finally allow to use SIMD for qbb. Another thing I'd like to try one day is to change the "black"
bitboard to an "us" bitboard, and implement a rotate function which turns the board around. This approach allows for simpler
move generation, since we suddenly only have to care for one side, namely, "us", independent from what color is about to move.

I hear you, and I agree that's all good concerns.

On the other hand, if you export the Internal modules as is -- that's a clear message to any users of these API's that they are on their own with regards to API stability.

[deepfire]

Also, my apologies for editing the comment message -- I get that you read this over a Braille device, so it's not exactly comfortable.