语法糖的严格定义？

Question

似乎在语言圣战中，人们不断地贬低任何他们认为没有什么特别用处的功能，就像“只是语法糖”。在这些争论中，“真实特征”和“句法糖”之间的界限往往变得模糊。你认为什么是语法糖的合理和明确的定义，避免它被定义为说话人/作者认为没有用的任何特性？

Answer 1

这样如何：“语法糖是一些功能的方便缩写，它没有引入任何有意义的抽象层。”

以a->b为例，正如您所指出的，它等同于(*a).b。这种表示法允许您以任何有用的、否则隐藏的方式来考虑代码吗？不，所以这是语法糖。

现在考虑一下a[i] == *(a + i)。想一想任何以任何实质性方式使用数组的C程序。你能想象不使用[]符号来理解它吗？多维数组？将数组看作整个单元是有意义的，而不是作为对连续内存块的开始的引用。如果您计划使用数组执行复杂的操作，那么了解数组在C中的工作方式确实是有帮助的，但是总是不得不认为“我需要将2*i字节的两位内存存储在a引用的内存位置的右侧”，这是没有意义的。数组的全部要点是能够抽象出将序列存储为一个相干单元的过程。[]符号为这种抽象提供了便利。这不是语法糖。

这并不意味着语法糖总是坏事。就像许多类似的词一样，它已经成为一个与“真实特征”相对立的绰号。但是LISP和Scheme，例如，如果不是let的缩写(和其他)，将是不可读的。

三元运算符<pred> ? <cnsq> : <alt>是另一个例子。语法糖可以帮助组织程序和删除多余的代码，这可能节省了维护工作。如果语法糖有助于消除编程中的语法障碍，它有时可能比增加“真正的特性”更可取。

引用R^5RS的话说，“编程语言的设计不应该将特性堆在特性之上，而应该消除使额外特性显得必要的弱点和限制。”IMHO，语法可以限定为一种弱点和限制，因此让程序员远离语法可以增加语言的表现力。

Answer 2

我不认为你能给语法糖下一个定义，因为这个短语是BS，可能会被那些在“真实操作系统”上谈论“真正的程序员”的人使用。

它的BS是因为“真正的特性”或“语法糖”的概念类似于没有真正的苏格兰人谬论。在这方面，这些短语是“临时试图保留毫无根据的断言”。这里的断言是，这里的特性很简单，因为您可以使用“真正的特性”。

它的BS，因为有人认为糖的使用应该是避让，因为你可以写一个bug，但是你应该坚持下去，因为它更难写bug。那不是很棒吗。同样的词组用同样的逻辑得出完全相反的结论。

它的BS是因为没有人引用可用性研究或缺陷计数研究来支持它们的可读性、可维护性或可能的缺陷参数。

这句话的意思是因为人们对等值的看法常常是错误的或变得错误的。例如，这个问题断言C#字符串是char数组的糖。他们不是。

然而，如果你想说两件事是糖，如果它们在语义上是等价的，那就帮助你去定义它，不管你想要什么。

如果你想对某人不屑一顾，你也可以用这个短语。

Answer 3

以下是一个相关概念的非常严格的定义:表现力

马蒂亚斯·费莱森：

论程序设计语言的表现力 附言是我唯一能找到的自由形式。

还可以在Java语言和闭包上看到这个条目。

实际上，如果仅通过进行局部更改就可以将某些内容更改为不需要语法的形式，那么它就是语法糖。例如，如果没有语法形式，您需要更改几个不同的代码位置，或者将片段移动到其他位置，那么这不是糖。

也就是说，恰当地使用语法糖是很好的。我认为任何一个Scheme程序员都希望有一个let特殊的表单，而不是创建一个新的匿名函数，然后应用它，这将做同样的事情。其目的是使代码更加清晰。