Questions tagged «pl.programming-languages»

编程语言尤其关注其语义。

3
非构造性证明的库里霍华德和程序
这是一个后续问题 证明与程序（或命题与类型）之间有什么区别？ 哪个程序对应于形式的非构造性（经典）证明？（假设是一些有趣的可确定的关系，例如，第个TM不会以步长停止。）Ť È ķ∀k T(e,k)∨¬∀k T(e,k)∀ķ Ť（Ë，ķ）∨¬∀ķ Ť（Ë，ķ）\forall k \ T(e,k) \lor \lnot \forall k \ T(e,k)TŤTeËekķk （ps：我之所以发布此问题，部分原因是我有兴趣在他的评论中进一步了解Neel所说的“ Godel-Gentzen翻译是一种延续通过的转变”的意思。）
6
为什么用自然而不是整数？
我对自然数为何受到编程语言理论和类型理论书籍（例如J. Mitchell，编程语言基础和B. Pierce，类型与编程语言）的作者如此钟爱的原因感兴趣。简单类型的lambda微积分的描述，尤其是PCF编程语言，通常是基于Nat和Bool的。对于使用和教学通用工业PL的人来说，用整数代替自然数更自然。您能提及PL理论家偏爱nat的一些好理由吗？除此之外，它还不那么复杂。有任何根本原因还是仅仅是一种荣誉？ UPD对于所有关于自然的“基本性”的评论：我对所有这些很酷的东西都非常了解，但是我更希望看到一个示例，说明在PL理论的类型理论中拥有这些属性确实至关重要。例如，广泛提到的归纳法。当我们有任何一种逻辑（简单地键入LC就是这种逻辑）时，就像基本的一阶逻辑一样，我们确实使用归纳法，但是对派生树（在lambda中也有）进行归纳。 我的问题基本上来自行业人士，他们想要获得一些编程语言的基本理论。他们曾经在程序中使用整数，却没有具体的论据和对正在研究的理论（在本例中为类型论）的应用，为什么只用nat来学习语言，他们感到非常失望。
4
最强大的解析器是什么？
作为附带项目，我正在使用Python编写语言。我从使用称为Ply的flex / bison克隆开始，但是在那种语法风格所能表达的功能方面，我处于优势地位，并且由于与阻抗不匹配，我对破解我的语言不感兴趣。工具。因此，我不反对自己编写。 那么，最强大的解析器类型是什么？欢迎引用论文（以及更多介绍性文章）。 （我知道“功能强大”的定义不明确，但让我们稍微放松一点，看看答案在哪里）
6
C实现的最大计算能力
如果我们按照本书（或您愿意的话，可以选择其他任何语言规范版本）进行阅读，那么C实现可以具有多少计算能力？ 请注意，“ C实现”具有技术含义：它是C编程语言规范的特定实例，其中记录了实现定义的行为。AC实施不必一定可以在实际计算机上运行。它确实必须实现整个语言，包括每个具有位字符串表示形式的对象和具有实现定义的大小的类型。 出于此问题的目的，没有外部存储。您可能执行的唯一输入/输出是getchar（读取程序输入）和putchar（写入程序输出）。同样，任何调用未定义行为的程序都是无效的：有效程序的行为必须由C规范以及附录J中列出的实现定义的行为的实现描述（对于C99）进行定义。请注意，标准中未提及的调用库函数是未定义的行为。 我最初的反应是，C实现只不过是有限的自动机，因为它对可寻址内存的数量有限制（您不能寻址的存储sizeof(char*) * CHAR_BIT位数更多，因为存储时不同的内存地址必须具有不同的位模式）在字节指针中）。 但是，我认为实现不仅仅可以做到这一点。据我所知，该标准对递归的深度没有限制。因此，您可以根据需要进行任意数量的递归函数调用，只有有限数量的调用中的所有调用都必须使用不可寻址（register）参数。因此，允许任意递归并且对register对象数量没有限制的C实现可以编码确定性下推自动机。 它是否正确？您能找到更强大的C实现吗？是否存在图灵完备的C实现？
2
类型空间中的对数或根运算是什么？
我最近在阅读计算的两个对偶：否定和小数类型。本文扩展了求和类型和乘积类型，为类型a - b和提供了语义a/b。 与加法和乘法不同，乘幂，对数和生根不是一个而是两个倒数。如果函数类型（a→b）是类型理论乘幂，则给定类型a → b（或b^a），具有类型logb(c)或类型意味着什么a√c？ 将对数和根扩展为类型是否有意义？ 如果是这样，这方面是否有任何工作，关于如何理解这些影响有什么好的指导？ 我尝试通过逻辑查找有关此问题的信息，希望Curry-Howard的信件对我有帮助，但无济于事。
5
是否有用于纯功能编程语言的带注释的形式验证系统？
ACSL（Ansi C规范语言）是C代码的规范，带有特殊注释，可对C代码进行正式验证。 我没有研究它，但是我想ACSL验证器中使用的形式方法将类似于Hoare Logic。但是对于纯函数式语言（例如Haskell），我无法想象将使用哪种形式主义进行形式验证。 除了纯函数式语言外，有人做过类似于ACSL的东西吗？如果不是，是否有针对功能语言的规范标注样式形式验证的研究？ 我知道有一种依赖类型，许多语言（Agda，Idris等）都支持这种类型，但是在Haskell中，不进行某种（不可读的）类型wizardry很难实现依赖类型。考虑到这一点，由于Haskell具有比Agda和Idris更好的库支持，我相信这样的功能形式验证系统可能会有用，但是我不知道是否对此进行了研究。
3
术语重写和模式匹配有什么区别？
由于Lambda Ultimate没有任何响应，因此我在这里再次尝试：术语重写系统用于自动定理，例如证明符号计算，当然也用于定义形式语法。有一些基于术语重写的编程语言，但据我了解，该概念更称为模式匹配。模式匹配在功能语言中被大量使用。巴里·杰伊（Barry Jay）创建了一个称为模式演算的整体理论，但他仅简要提及术语重写。我觉得它们都指的是相同的基本思想，因此您可以同义地使用术语重写和模式匹配吗？
6
我应该如何考虑证明网？
斯蒂芬·吉梅内斯（Stephane Gimenez）在回答这个问题时指出了一种用于线性逻辑证明的多项式时间归一化算法。吉拉德（Girard）论文中的证明使用证明网，这是我实际上不太了解的线性逻辑的一个方面。 现在，我曾经尝试过在证明网上阅读论文（例如Pierre-Louis Curien的说明），但我并没有真正理解它们。所以我的问题是：我应该如何考虑它们？我所说的“如何思考它们”不仅是指它们背后的非正式直觉（例如，它们在计算上的行为方式，还是它们与序列的关系），还有关于它们的哪些定理，我应该自己证明才能真正得到。 在回答这个问题时，您可以假设（1）我很好地了解线性逻辑的证明理论（包括诸如消除消除证明的进行方式，以及采用集中形式之类的东西），（2）就相干空间而言，它们的分类语义或通过Day卷积，以及（3）GoI构造的最基本基础。
2
依赖类型是否给您所有子类型化功能？
类型和编程语言将重点放在子类型上，但是据我所知，子类型似乎并不是特别基础。与依赖类型相比，子类型化还给您更多的好处吗？使用依赖类型必然会花费更多工作，因此我可以理解为什么子类型在实践中可能会有用。但是，我对类型理论作为数学的基础比对编程语言的基础更感兴趣，我应该特别注意子类型化吗？
4
理论CS何时（或应该）关心直觉证明？
据我了解（很少，所以请纠正我的错误！），编程语言理论通常与“直觉”证明有关。在我自己的解释中，该方法要求我们认真考虑计算对逻辑和可证明性的后果。除非存在一种从假设中构造后果的算法，否则证明就不存在。我们可能会拒绝作为公理排中的原则，例如，因为它表现出的一些对象，要么是或¬ X，nonconstructively。XXX¬ X¬X\lnot X 以上哲学可能使我们更倾向于直觉上有效的证明，而不是没有证明的证明。但是，在理论CS的其他领域中，我对论文中实际使用直觉逻辑没有任何担忧。我们似乎很高兴使用经典逻辑来证明我们的结果。例如，您可能想像使用排除中间的原理来证明一种算法是正确的。换句话说，我们在结果中关注并认真考虑计算受限的宇宙，但不一定要在我们对这些结果的证明中。 1.理论CS的研究人员是否曾经担心编写直觉上有效的证明？我很容易想到理论计算机科学的一个子领域，该子领域试图了解TCS结果（尤其是算法结果）何时包含直觉逻辑（或更有趣的是，当它们不包含）。但是我还没有碰到任何东西。 2.他们应该有什么哲学上的争论吗？似乎可以声称，计算机科学的结果应该在可能的情况下凭直觉来证明，我们应该知道哪些结果需要例如 PEM。有没有人试图提出这样的论点？也许已经达成共识，这个问题不是很重要？ 3.作为一个附带的问题，我很好奇要知道在哪些情况下这实际上很重要：在传统逻辑中，是否有重要的TCS结果已知，而在直觉逻辑中却没有？或怀疑不符合直觉逻辑。 对于这个问题的柔和性表示歉意！在听取专家意见后，可能需要重新措辞或重新解释。
2
类型系统是否有表达层级？
受到复杂性理论中广泛的层次结构的启发，我想知道类型系统是否也存在这种层次结构。但是，到目前为止，我发现的两个示例都更像是清单（具有正交特征），而不是层次结构（具有越来越多的表现型类型系统）。 我发现的两个示例是Lambda多维数据集和k级多态性的概念。第一个是具有三个选项的清单，第二个是真实的层次结构（尽管我相信，针对k的特定值对k排序并不常见）。我知道的所有其他类型的系统特征大部分都是正交的。 我对这些概念很感兴趣，因为我正在设计自己的语言，并且很好奇它在当前现有类型系统中的排名（据我所知，我的类型系统有些不常规）。 我意识到“表达性”的概念可能有点含糊，这可以解释为什么类型系统在我看来像清单。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.