F # binary variable serialization

Question

I used binary serialization to save an F # entry from a C # class. Everything is working fine:

F #:

type GameState = { LevelStatus : LevelStatus Grid : Variable<Option<Ball> [,]> ... } let game_state : GameState = aGameState() 

WITH#:

 public void OnSaveGame() { using (var stream = File.Open("game_status.sav", FileMode.Create)) { var binary_formatter = new BinaryFormatter(); binary_formatter.Serialize(stream, PuzzleBobble.game_state); } } 

Now, I am refactoring my F # module, and I would like to have a mutable record for serialization:

 let mutable game_state = aGameState() game_state <- myGameState() 

This way the file is created, but when I try to deserialize it, I get a null object.
I have not changed anything in my previous implementation, except for the added mutable keyword.

My question is: is there anything wrong with serializing a mutable F # record? Or serialize it correctly and should I look for another error somewhere else in my code?

EDIT:

Even write access using methods such as suggested by @Brian does not seem to work.

Here are a few more details. When I deserialize a previous saved object this way (which works without the declared variable game_state):

 public void OnLoadGame() { using (var stream = File.Open("game_status.sav", FileMode.Open)) { var binary_formatter = new BinaryFormatter(); try { GameLogic.GameState state = binary_formatter.Deserialize(stream) as GameLogic.GameState; GameLogic.load_game_state(state); } catch (ArgumentNullException e) { Console.WriteLine(e.Message); } } } 

I get the following exception:

'System.ArgumentNullException' in the FSharp.Core.dll file

Answer 1

I once saw some strange error in which variable variables of variables in F # libraries were not correctly initialized, is it possible that you are doing this?

If you change the code to determine

 let getGameState() = game_state let setGameState(x) = game_state <- x 

and then use the get / set functions, and not refer to the variable to be changed directly, does the problem disappear? If so, it could be an exotic compiler bug that we know about.