Design thoughts

[mlutze]

Design thoughts

[JonathanStarup]

1. yes, my code has been missing some reorganization. I think all of our data structuring could use a rethink to avoid hassle, coupling, and redundancy.
2. I agree in principle but i think that the board does not contain extranous information, maybe if it changes from its current definition.
3. i think that should be possible right now quite easily, i can try it out next fine i code.
4. i think both are valid but mutability should only be for performance. it certainly looks like a monadic pattern

[mlutze]

Here's my current thought on GameState etc.

GameState currently has

• states: Map[PlayerId, (Int32, Map[String, String])]
• positions: Map[PlayerId, Position]
• board: Board

And Board contains Tiles which contain Players which contain MoveLogic

I think we should essentially get rid of Player and instead store the relevant data in the maps.

So GameState becomes (states, positions, logics, board). And things dealing with Player instead deal with PlayerId.

Then we separate GameState into PublicState and PrivateState. This way we keep the states and logic of all the AIs separate from each other. So the getMove function for AIs has the signature: (Int32, Map[String, String]) -> PublicState -> ((Int32, Map[String, String]), Move)

[JonathanStarup]

I agree generally.

• I still think the MoveLogic should be regioned, which removes the Int32, Map... and States map which simplifies things.
• Our running of the board has become stateful but with the above change, why is it stateful? the positions map is just there for performance right? it can be computed from the board

[mlutze]

* I still think the MoveLogic should be regioned, which removes the Int32, Map... and States map which simplifies things.

Yes, I agree if it can be made to work, but I am not yet convinced it can work :)

* Our running of the board has become stateful but with the above change, why is it stateful? the positions map is just there for performance right? it can be computed from the board

Positions is indeed redundant. I don't totally understand what you mean by stateful though. Here I'm mostly just rearranging where the data is located.

[mlutze]

I've run into a problem with the Impure to Pure MoveLogic function.

    type alias MutMoveLogic[m: Region -> Type, r: Region] =
        (GameState, PlayerId, m[r]) -> Move \ r

    def toMoveLogic(logic: MutMoveLogic[m, r]): MoveLogic with State[a] = {
        def f(gs, id, state) = region reg {
            // call logic() with conversions
        }
    }

The issue is that here, we want the r of MutMoveLogic[m, r] to unify with reg. But r is already bound by the function. For example we could call toMoveLogic with logic: MutMoveLogic[T, Static] which would never unify with reg.

What we really need is a rank-2 type, so MutMoveLogic is instead MutMoveLogic[m: Region -> Type] = forall r, (GameState, PlayerId, m[r]) -> Move \ r. But Flix doesn't have rank-2 types, so we need some kind of workaround.

[JonathanStarup]

I've run into a problem with the Impure to Pure MoveLogic function.

    type alias MutMoveLogic[m: Region -> Type, r: Region] =
        (GameState, PlayerId, m[r]) -> Move \ r

    def toMoveLogic(logic: MutMoveLogic[m, r]): MoveLogic with State[a] = {
        def f(gs, id, state) = region reg {
            // call logic() with conversions
        }
    }

The issue is that here, we want the r of MutMoveLogic[m, r] to unify with reg. But r is already bound by the function. For example we could call toMoveLogic with logic: MutMoveLogic[T, Static] which would never unify with reg.

What we really need is a rank-2 type, so MutMoveLogic is instead MutMoveLogic[m: Region -> Type] = forall r, (GameState, PlayerId, m[r]) -> Move \ r. But Flix doesn't have rank-2 types, so we need some kind of workaround.

yea I had this problem too. difficult to solve. In my attempt, I added a region argument to toMoveLogic such that the caller, which hopefully can instantiate the region type parameter, can make them have the same region.