Saved state for activities

Nadie ha tomado este issue todavía.

Students would like to be able to save the state of their programs and load it back again. They could save games, edit and work with documents in which they record data and manipulate it, and so on. Very exciting!

At face value, this seems impossible to implement, because there is no type class constraint on the state type, meaning that it's opaque to the framework code. and cannot be serialized.

Here's an idea for a solution: automatically derive Generic for all data types, and add wildcard constraints to all functions. This can be done in a source plugin. But here's the problem with that. Even if we can dig around inside state with GHC generics, it can contain first-class functions and infinite data structures, which are not serializable. So this solution doesn't work for all cases. It means you have to be careful what you put in your state if you want to be able to save.

Here's a different idea for a solution: use event logs as the state type. This is the same trick from @nomeata's work on multi-player games, where different clients synchronize their state by consistently replaying logs. But, here's the problem with event logs: they grow over time, and never shrink. That's fine for keeping two clients in sync (at least as long as they remain connected...) but for a long-term saved-game format or something like that, there's unbounded work that must be done to restore a saved state. This is less than ideal.

Is it possible to combine these ideas? Does there exist some way of storing serialized state when it exists, but an event log when it doesn't, and possibly using observable sharing to identify shortcuts in the event log where events that only modify serializable parts of the state can be merged? Maybe. Sounds complicated, but it's worth a thought.

Comienza revisando los dos enfoques propuestos en el issue: serialización genérica mediante un plugin de origen y reproducción del registro de eventos. Investiga cómo afectan a cada enfoque el estado opaco, las funciones de primera clase, las estructuras de datos infinitas y los registros en crecimiento. Se considerará completado cuando se documente un diseño viable o se establezca claramente por qué la funcionalidad solicitada para guardar el estado no es viable.

Escrito por el modelo de indexación a partir del texto del issue.