问题描述
从鸟的角度来看，我的问题是：Haskell 中是否存在用于 as-is 数据序列化的通用机制？
简介
问题的根源确实不在 Haskell 中。有一次，我尝试序列化一个 Python 字典，其中对象的哈希函数非常繁重。我发现在python中，默认的字典序列化并没有保存字典的内部结构，而只是转储了一个键值对列表。结果，反序列化的过程很耗时，也没有办法与之抗争。我确信在 Haskell 中有一种方法，因为在我看来，使用 BFS 或 DFS 自动将纯 Haskell 类型传输到字节流应该没有问题。令人惊讶，但事实并非如此。讨论了这个问题here（引文如下）
目前没有办法在不修改HashMap库本身的情况下使HashMap可序列化。如@mergeconflict 的回答所述，无法使用独立派生使 Data.HashMap 成为 Generic 的实例（用于谷物），因为 Data.HashMap 不导出其所有构造函数（这是 GHC 的要求）。因此，序列化 HashMap 的唯一解决方案似乎是使用 toList/fromList 接口。
当前问题
我对 Data.Trie bytestring-trie package 有同样的问题。为我的数据构建一个尝试非常耗时，我需要一种机制来序列化和反序列化这个轮胎。但是，看起来像前一种情况，我看不出如何使 Data.Trie 成为 Generic 的实例（或者，我错了）？
所以问题是：
-
是否有某种通用机制可以将纯 Haskell 类型投影到字节字符串？如果不是，是基本限制还是只是缺乏实现？
-
如果不是，修改 bytestring-trie package 以使其成为 Generic 的实例并使用
Data.Store进行序列化的最轻松的方法是什么
解决方法
- 有一种使用 compact regions 的方法，但有一个很大的限制：
我们的二进制表示包含指向区域中对象信息表的直接指针。这意味着接收流程的信息表必须以与原始流程完全相同的方式进行布局；实际上，这意味着使用静态链接，使用完全相同的二进制文件并关闭 ASLR。这个 API 不做任何安全检查，如果你弄错了，可能会出现段错误。不要在不受信任的输入上运行它。
这也让我们深入了解目前不可能实现的通用序列化。数据结构包含非常具体的指针，如果您使用不同的二进制文件，这些指针可能会有所不同。将原始字节读入另一个二进制文件将导致无效指针。
有一些关于弱化此要求的讨论 in this GitHub issue。
- 我认为正确的方法是在上游打开问题或拉取请求以导出 internal module 中的数据构造函数。这就是
HashMap发生的情况，它现在可以在 its internal module 中完全访问。
更新：似乎已经有类似的open issue。