通过拥有“依赖类型”，我们可以获得什么？

我以为我正确理解了依赖类型（DT），但是这个问题的答案是：https : //cstheory.stackexchange.com/questions/30651/why-was-there-a-need-for-martin-l%C3% B6f要创建直觉型的理论使我产生了其他想法。

在阅读了DT并试图理解它们之后，我想知道，从DT的概念中我们可以得到什么？它们似乎比简单的lambda演算（STLC）更灵活，功能更强大，尽管我无法确切地理解“如何/为什么”。

用STLC无法完成的DT可以做什么？似乎增加DT会使理论变得更加复杂，但是有什么好处呢？

从以上问题的答案：

依赖类型由de Bruijn和Howard提出，他们希望将Curry-Howard对应关系从命题逻辑扩展到一阶逻辑。

从某种程度上讲，这似乎是有道理的，但我仍然无法掌握“如何/为什么”的全局图？也许一个例子明确表明了将CH对应关系扩展到FO逻辑可以帮助理解DT有什么大不了的地方？我不确定我也应该理解这一点。

logic type-theory intuition

— 博士
source

你用谷歌搜索了吗？您是否听说过基于依赖类型构建的定理证明者Coq？您知道使用Coq证明4色定理吗？

— 戴夫·克拉克

我是真的从直觉上来说，DT赋予类型理论的额外“力量”（缺少更好的词）对Google来说是什么呢？

— 博士

为什么？依赖类型使您可以键入更多程序，同时仍保持类型安全。怎么样？通过使用程序参数化类型。

— Martin Berger'3

@MartinBerger-您能否详细介绍“更多程序”？从理论上讲，我能做什么或需要什么？

— 博士

@DaveClarke带有花哨类型的Coq已被用于做花哨的事情，并不意味着这些花哨的东西需要那些花哨的类型。例如，Twelf取得了重大成功（例如SML正确性的证明），并且它只是二阶的，而不是高阶的。我已经看到一些大型系统仅通过一阶逻辑证明。

— 吉尔（Gilles）'所以

Answers:

$\lambda$ $List_{2*3+4}(\alpha)$ $10$ $\alpha$ $2*3+4$

区分依赖类型和非依赖类型的关键规则是应用程序：

\frac{Γ ⊢ M : A \to B Γ ⊢ N : A}{Γ ⊢ M N : B} \frac{Γ ⊢ M : Π x^{A} . B Γ ⊢ N : A}{Γ ⊢ M N : B {N / x}}

$\newcommand{\TYPES}[3]{#1 \vdash #2 : #3} \newcommand{\SUBST}[2]{\{#1/#2\}} \frac{ \TYPES{\Gamma}{\color{red}{M}}{A \rightarrow B} \qquad \TYPES{\Gamma}{\color{red}{N}}{A} }{ \TYPES{\Gamma}{\color{red}{MN}}{B} } \qquad \frac{ \TYPES{\Gamma}{{\color{red}M}}{\Pi x^A. B} \qquad \TYPES{\Gamma}{\color{red}{N}}{A} }{ \TYPES{\Gamma}{{\color{red}{MN}}}{B\SUBST{{\color{red}N}}{x}} }$

左侧有STLC，其中前提中的程序仅“流入”结论程序。相反，在右边的从属应用程序规则中，来自右边前提的程序 “流入” 结论的类型。 $N$ $^1$

为了能够通过程序对类型进行参数化，从属类型的语法必须更丰富，并且为了确保类型格式正确，我们使用了第二个“类型系统”，称为类型，该类型对类型进行约束。这种分拣系统本质上是STLC，但“一级升级”。

依赖类型有很多解释。一些例子。

Bove和Dybjer撰写的工作中的依存类型。
从属类型，由Aspinall和Hofmann撰写。
Norda和Chapman 撰写的Agda中的依存类型编程。
Barendregt撰写的Lambda Calculi with Types。

$^1$ ^{就颜色而言：对于非从属类型，结论中的黑色表达式是根据前提中的黑色表达式构造的，而结论中的红色表达式是根据前提中的红色表达式构造的。对于从属类型，可以通过使前提的黑色部分由前提的红色和黑色部分构成来混合颜色。}

— 马丁·伯格
source

现在，这很有意义。这可能很明显，但是由于某些原因，我无法对此付诸行动。欣赏从评论到答案的过渡。不幸的是，该问题已被投票关闭，但我很高兴得到答案:)

— PhD

我不为您的示例感到疯狂，因为列表长度只是您可以在类型中擦除的内容，并且可以使程序谈论普通（未索引）列表。可能需要注意的是，在进行这种擦除之后，某些类型的类型仍然不能很好地进行类型化，例如类型的程序，其中和。

A r r n

$\mathrm{Arr}\ n$

A r r 0 = n a t

$\mathrm{Arr}\ 0 = \mathrm{nat}$

A r r (n + 1) = n a t \to A r r n

$\mathrm{Arr}\ (n+1) = \mathrm{nat}\rightarrow\mathrm{Arr}\ n$

— cody

@cody我不确定您的意思。依存类型在以下意义上具有（或可以设置为具有）类型擦除：对于所有可键入的P： iff，其中是运行时缩减关系。（这是一个简化的描述，其中函数擦除将带有类型注释的程序映射到没有注释的“相同”程序。）也许您是说不同的东西吗？

P ⇓ V

$P\Downarrow V$

e r a s e (P) ⇓ e r a s e (V)

$erase(P)\Downarrow erase(V)$

⇓

$\Downarrow$

— Martin Berger

@MartinBerger：是的，在这种情况下，我说的是擦除依赖类型中的依赖以获取简单类型。我现在只能指出的唯一例子是证明归一化归一化的证明（例如在Barendregt的书中）。

F_{ω}

$F_\omega$

C o C

$\mathrm{CoC}$

— cody 2015年

@cody我认为将这种类型的擦除称为罕见。什么叫更好的名字？也许类型简化？

— Martin Berger

将类型声明视为断言。当前，您只能说isInt32（），isCharPtr（）等。选择这些各种断言可以在编译时进行检查。但是这个概念可以扩展为：isCharPtr（）&& isNotNull（）。可空指针是一个巨大的问题。指针不应为默认姿势，不能为空，因为可空指针是在不知道它是否为空的情况下不可取消引用的类型。类似的问题是：isPositiveInteger（）或isEvenNaturalNumber（）。

— 抢
source