假设 F* 中的 val 和 opaque 类型构造
Assume val and opaque type constructs in F*
我是 F* 的新手，虽然教程写得很好，但我缺少一些很好的 API 页面以供参考。
所以我需要以下结构的准确含义：
assume val name: type
我会说这一行将正在使用的名称注册到求解器中？
opaque type name (...) ...
调用类型不透明有什么作用？它可能需要的参数列表怎么样？
请附上您可能用于给出此答案的参考资料。
assume val name : Type的意思是假设一个公理存在Type，可以被name访问。由于它是一个公理，它不会有一个实现，并且如果被误用（例如假设一个自然数严格小于 0）会导致逻辑上的不一致。
F* 教程与去年发生的多项更改并不完全同步，opaque 就是该问题的一个实例。
来自编译器源代码（在撰写本文时，在 src/tosyntax/FStar.ToSyntax.fs 中）：
The 'opaque' qualifier is deprecated since its use was strangely schizophrenic. There were two overloaded uses:
(1) Given 'opaque val f : t', the behavior was to exclude the definition of 'f' to the SMT solver. This corresponds roughly to the new 'irreducible' qualifier.
(2) Given 'opaque type t = t'', the behavior was to provide the definition of 't' to the SMT solver, but not to inline it, unless absolutely required for unification. This corresponds roughly to the behavior of 'unfoldable' (which is currently the default).
我是 F* 的新手，虽然教程写得很好，但我缺少一些很好的 API 页面以供参考。
所以我需要以下结构的准确含义：
assume val name: type
我会说这一行将正在使用的名称注册到求解器中？
opaque type name (...) ...
调用类型不透明有什么作用？它可能需要的参数列表怎么样？
请附上您可能用于给出此答案的参考资料。
assume val name : Type的意思是假设一个公理存在Type，可以被name访问。由于它是一个公理，它不会有一个实现，并且如果被误用（例如假设一个自然数严格小于 0）会导致逻辑上的不一致。
F* 教程与去年发生的多项更改并不完全同步，opaque 就是该问题的一个实例。
来自编译器源代码（在撰写本文时，在 src/tosyntax/FStar.ToSyntax.fs 中）：
The 'opaque' qualifier is deprecated since its use was strangely schizophrenic. There were two overloaded uses: (1) Given 'opaque val f : t', the behavior was to exclude the definition of 'f' to the SMT solver. This corresponds roughly to the new 'irreducible' qualifier. (2) Given 'opaque type t = t'', the behavior was to provide the definition of 't' to the SMT solver, but not to inline it, unless absolutely required for unification. This corresponds roughly to the behavior of 'unfoldable' (which is currently the default).