Questions tagged «semantics»

7
什么是指称语义？
在另一个线程上，Andrej Bauer将指称语义定义为： 程序的含义是程序各部分含义的函数。 使我困扰的是该定义，它似乎并未从通常被认为是非名词性语义的东西（即结构操作语义）中分离出通常被认为是指称语义的东西。 更准确地说，这里的关键要素是语义的模块化或组合性，或者换句话说，它们是根据程序的抽象结构定义的。 由于当今大多数（全部？）形式语义趋向于结构化，这是否是必需的定义？ 所以，我的问题是：什么是指称语义？
7
有关编程语言语义的书籍
我一直在阅读Nielson＆Nielson的“ 应用程序语义学 ”，我真的很喜欢这个主题。我想再写一本关于编程语言语义的书-但我确实只能读一本书。 我看了一看Turbak / Gifford的书，但是书太长了。我以为Winskel会没事的，但是我无法使用它（它不在我们的大学图书馆中，而且我缺钱），而且我甚至不确定它是否过时。Slonneger看起来还可以，但是实际部分使它有些长，我对他的风格不太满意。 所以我的问题是- 温斯克尔是一本好书吗？而且过时了吗？ 此外，是否还有其他有关此主题的简明书籍？
4
为什么我们需要谓词逻辑的形式语义？
考虑这个问题解决了。我不会选择最佳答案，因为所有答案都有助于我对该主题的理解。 不确定通过正式定义谓词逻辑的语义有什么好处。但是我确实认为拥有正式的证明演算很有价值。我的观点是，我们将不需要形式语义来证明证明计算的推理规则。 我们可以定义一个微积分，模仿“思维定律”，即数学家数百年来一直使用的推理规则来证明其定理。这样的计算已经存在：自然演绎。然后，我们将微积分定义为合理且完整。 这可以通过认识到谓词逻辑的形式语义仅仅是一个模型来证明。该模型的适当性只能凭直觉来证明。因此，通过参照形式语义论证明自然推论是合理和完整的，并不能使自然推论更“真实”。如果我们直接直观地证明自然演绎规则是正确的。使用形式语义学绕道而行对我们没有任何帮助。 然后，将自然演绎定义为合理且完整的，我们可以通过证明它们产生的证据可以转换为自然演绎，反之亦然来证明其他演算的正确性和完整性。 我以上的观点正确吗？为什么通过形式语义证明证明演算的正确性和完整性很重要？
2
TeX（作为一种编程语言）的语义是否曾经被形式化？
在我看来，使用的宏语言可以看作是某种术语重写系统或某种具有按名字调用作用域的编程语言。ŤËXŤËX\TeX 甚至引擎的现代实现（例如）都以非常直接的方式解释代码，而且我不知道有任何优化执行的尝试（就像现代的优化解释器可以做到的那样）。但是，为类的语言设计正确的优化过程将非常困难，因为宏重新定义可以具有“远距离操作”，并且具有通过按名称调用它们来重新定义宏的能力。X e TŤËXŤËX\TeXŤX Ë ŤËXXËŤËX\mathit{Xe}\TeXŤËXŤËX\TeX 因此，为实现一种假设的优化解释器在实践中听起来是一个非常困难的问题，但同时也是一个非常有用的问题，因为在数学和科学领域都被广泛使用，并且编译速度慢是该系统的一个已知缺点。请注意，大部分时间都花在解释代码上，而不是在计算实际的排版，尤其是在使用计算量大的包（例如）时。ŤŤËXŤËX\TeXŤËXŤËX\TeXtikz 语言的正式语义可能是解决该问题的开始。那么编程语言的语义是否已被形式化了？ŤËXŤËX\TeX
5
编译器正确性证明
我正在寻找涵盖编译器正确性证明的教程材料，最好是在初等研究生的水平上使用指称方法。 另外，您是否知道一些我可以用来说明问题的简单编译器示例？（我想到的第一个示例是从infix到postfix表达式的转换器。但是除了如何对语法进行归纳之外，它没有显示出任何有趣的东西。）
4
语义如何处理副作用？
在Anthony Aaby的“ 语义学编程语言简介”部分中，他做了以下观察： 编程语言的语义方面的许多工作是由尝试构建和理解命令式程序（带有赋值命令的程序）时遇到的问题所激发的。由于赋值命令会将值重新分配给变量，因此赋值可能在程序的远处产生意外的影响。 这让我印象深刻，承认允许副作用会激发语义工作的大部分。 编程语言中副作用的存在如何影响将程序映射到计算模型的能力？是否有管理状态的方法可以改善此过程，同时仍然允许副作用？
4
命令性语言与功能性语言之间的区别是什么？
我正在阅读西蒙·佩顿·琼斯（Simon Peyton Jones）的《函数式编程语言的实现》，有一个说法让我有些惊讶（第39页）： 与命令式语言相比，功能语言在很大程度上是彼此的语法变体，语义上的差异相对较小。 现在，它写于1987年，我对此主题的想法可能会受到当时不流行或不流行的现代编程语言的影响。但是，我发现这有点难以置信。例如，我认为所描述的Miranda编程语言（Haskell的较早版本）与严格的语言（如ML）相比，语义要多得多，而不是说C必须进行Pascal甚至C进行小规模的交谈（尽管我承认C ++对他的观点提供了一些验证：-)。 但是话又说回来，我是基于我的直觉理解。西蒙·佩顿·琼斯（Simon Peyton Jones）的说法是否正确，还是有争议的观点？
2
程序翻译的完全完整性与完全抽象
编译器验证工作通常归结为证明编译器完全抽象：它保留并反映（上下文）对等。 代替提供完全抽象样张，由长谷川[一些最近（分类基于）编译器核查工作1，2 ]和艾格等。等 [ 3 ]证明了各种CPS翻译的完全完整性。 问题： 完全完整性和完全抽象之间有什么区别？ 在我看来，完整性就像翻译的对等反映，而完整性似乎是对等保存的结果。 注意：Curien [ 7 ]和Abramsky [ 8 ]都探讨了可定义性，完全抽象以及某种程度上完全完整性之间的关系。我怀疑这些资源可能可以回答我的问题，但经过表面阅读后，我尚未确认。 某些背景：Abramsky和Jagadeesan [ 4 ] 提出了“完全完整性”一词，用以描述乘法线性逻辑的博弈语义模型的正确性。 Blute [ 5 ]提供以下定义： 令FF\mathcal{F}为自由类别。我们说一个明确的模型 MM\mathcal{M}是全面完成 FF\mathcal{F}或者说我们有 充分完整性FF\mathcal{F}相对于MM\mathcal{M}，如果，相对于发电机的一些解释，独特的无仿函数[[−]]:F→M[[−]]:F→M[\![ - ]\!] : \mathcal{F} \rightarrow \mathcal{M}已满。 据我所知，[ 6 ]中的长谷川是第一个采用完全完整性来描述程序翻译而不是分类语义模型的人。在这种情况下，吉拉德从简单类型的Lambda演算转换为线性Lambda演算。后来，在[ 1 ]，他定义了CPS翻译的全完整性(⋅)∘(⋅)∘(\cdot)^\circ为： Γ∘;∅⊢N:(σ∘→o)⊸oΓ∘;∅⊢N:(σ∘→o)⊸o\Gamma^{\circ};\emptyset \vdash N : (\sigma^\circ \rightarrow o) \multimap oΓ⊢M:σΓ⊢M:σ\Gamma \vdash …
3
我们什么时候可以说两个程序不同？
Q1。我们什么时候可以说两个程序（用某些编程语言，如C ++编写）不同？ 第一个极端是，如果两个程序相同，则它们是等效的。另一个极端是，如果两个程序计算相同的功能（或在相似的环境中显示相同的可观察行为），则它们是等效的。但这并不是很好：并非所有检查素数的程序都相同。我们可以添加一行代码，而不会影响结果，我们仍将其视为同一程序。 Q2。程序和算法是同一种对象吗？如果不是，算法的定义是什么？它与程序的定义有何不同？我们什么时候可以说两种算法是等效的？
2
零类型的方程式定律是什么？
免责声明：虽然我很关注类型理论，但我并不认为自己是类型理论的专家。 在简单类型的lambda演算中，零类型没有构造函数，并且具有唯一的消除符： Γ⊢M:0Γ⊢initial(M):AΓ⊢M:0Γ⊢initial(M):A\frac{\Gamma \vdash M \colon 0}{\Gamma \vdash initial (M) \colon A} 从种属的观点来看，方程式 initial(M1)=initial(M2)initial(M1)=initial(M2)initial (M_1) = initial(M_2)是显而易见的（当类型有意义时）。 但是，从这个角度来看，我还可以推断出，当M,M′:0M,M′:0M,M' \colon 0，：M=M′M=M′M = M'。这种推论似乎更强，尽管显示它的特定模型使我难以理解。 （尽管我有一些证明理论上的直觉：您使用哪种矛盾来获得居民并不重要，但是可能会有不同的矛盾证明。） 所以我的问题是： 零类型的标准方程式是什么？ 它们中的任何一个被归类为ηη\eta或ββ\beta定律吗？
2
减少策略和评估策略有什么区别？
从Wikipedia上的评估策略文章中： λ演算中的约简策略的概念相似但又截然不同。 从Wikipedia上的减少策略文章中： 它与计算机科学中的评估策略概念相似但有细微差别。 这两篇文章所暗示的评估策略与减少策略之间的微妙区别是什么？它们只是来自不同领域的两个相似概念吗？
1
程序最小化
电路最小化是最小化给定电路尺寸的问题。一般程序有什么类似的东西吗？ 我的问题尤其是- 是否存在用于最小化给定程序的指令数量的算法。我知道这是一个无法确定的问题，但我不是在寻找能够返回最佳结果的解决方案。 虽然可以应用现有的编译器转换来完成此操作，但我正在寻找不需要定义一组非常狭窄的转换和算法来预先搜索它们的东西。 编辑：我还有另一个问题是，是否可以进行一个合理而完整的演算，以使我们能够探索这种语义上等效的程序的整个空间，或者这是不可能的。
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.