你是想说PLT Redex那样可以直接用来表达小步操作语义的东西吗?
那我觉得你可能不知道操作语义是什么意思, 因为操作语义就是这样很具体的东西 (大概就是一个转换系统). 我会推荐你读读A Structural Approach to Operational Semantics和Semantics Engineering with PLT Redex.
如果把开发一门编程语言对比开发一个桌面应用,个人认为语法设计对应前端设计,如输入框位置、文本标签内容、排列顺序等;而语义定义则对应应用的功能分析,如用户输入出发和目的地,获得所有车次。
看到你的“从刻画编程语言的语义开始”,就想到是否能在语言语法设计之前先形式化描述语义。
抽象句法树作为媒介已经足够具体而容易理解, 足够抽象而可以适应实际编程语言的需求. 如果需要更加抽象, 你就要转向范畴逻辑和范畴语义.
个人设想的是不依赖于具体语法的对编程语言语义的描述,不确定与抽象程度是何关联。举个具体例子,如下面的 BNF:
<exp> ::= <int>
| (<op> <exp> <exp>)
<op> ::= + | *
对应语义描述:已知至少两个整数,指定求和或求积,得到所有整数的和或积。
有没有一种可能是, 抽象句法树就是来干这个活的.
如果指的是抽象语法树(AST),它毕竟还是保留了一部分语法信息吧:
+
/ \
5 +
/ \
2 3
而上述语义描述并不包含“树”的具体结构信息。
如果你没有对于语法的信息, 你怎么建立语义呢? 我想Alan Perlis说得很好: Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process. 但是, 尽管你可以通过添加抽象层来推迟一些东西的确定, 你不能推迟所有的东西, 那等于什么信息都没有.
如果你没有对于语法的信息, 你怎么建立语义呢?
上面的网络应用例子,在完全不牵涉前后端设计的情况下,仍能先描述各项功能。
之所以提出不依赖具体语法设计的语义描述方法是否可行,是因为看到自研的绝大多数编程语言项目没有在语法设计前对该语言的语义(或者说“功能”更确切)作详细描述。个人认为,“语”是为了解决实际问题而生,而语法是在能解决问题的前提下进行的具体设计。同样的语义,各种不同编程语言可能有不同的语法设计,这是 【转】 Programming Languages Are Overrated 提到 “a typical project can be completed in any of them” 的一个原因。如果能够从功能上描述,那么各种编程语言项目可以有一个共用的出发点,也可减少重复劳动。
另外,语义是功能的一方面,而反馈信息、性能、目标平台等是其他的方面。换言之,希望编程语言项目能够从成熟的软件开发过程中吸取经验。相对于项目中具体设计、实现、性能优化等等,个人看来需求和功能分析是相当欠缺的部分。
虽然我在上文已经说了几次了, 但你好像没有正确理解抽象句法树何以抽象. 按照你的想法来看的话, 先停留在抽象句法树, 之后再设计具体的句法也是完全可以的. 实际上, 按照你上文所说的功能分析和前端设计, 功能分析已经induce了前端设计所需要满足的约束 (你需要实现怎样的功能, 功能的一个输入则必须对应在前端具有一个输入的手段). 语义也是如此, 最终它会induce构造和解构句法的手段, 那么抽象句法树是既具体也抽象的最为正常的中间媒介.
(我非常怀疑你所设想的东西是将各种各样的语言都转换为同一个中间语言这种事情, 这种事情当然可以在某种程度上施行, 但是实际进行却有各种各样的麻烦.)
你需要实现怎样的功能, 功能的一个输入则必须对应在前端具有一个输入的手段
当然,但在功能分析时,完全可以脱离输入的具体形式/手段进行描述。就像可以这样几种形式:
起点:__ 终点:__
起点和终点分别是:__ -> __
__ 到 __
而语义都是:由用户指定出发和目的地
按照你的想法来看的话, 先停留在抽象句法树, 之后再设计具体的句法也是完全可以的.
如 楼上 所言,个人设想的是比抽象语法树的语法信息更少的描述形式。
那你真要来点范畴逻辑
你这个 BNF 描述的就是所谓抽象语法树, 且不涉及语义. 从这个语法描述中, 我看不出 +
和 *
这两个符号的意思. 你没有指定 + 1 1
, * 2 3
这些表达式求值的结果.
这些缺少的东西, 才是所谓「语义」.
咨询后,目前认识如下:
我之前设想的是描述语言的功能,而暂未考虑对其进行验证。以上面例子,功能是“对两个或多个整数进行求和”。用范畴逻辑等工具对“什么是整数”、“什么是求和”等等进行形式化定义,可以验证该功能是否合理、与其他功能是否有矛盾等等,但不具备这些定义不妨碍进行功能描述。换言之,在功能描述时,暂时借助一般共识的“整数”、“加法”等概念。
在功能描述时,暂时借助一般共识的“整数”、“加法”等概念。
这才是研发工业语言最经济的做法
之前的问题“有没有对编程语言的语义作描述的编程语言呢?”的确唐突。
也许应另开一个话题:如何对编程语言进行需求分析。因为编程语言在功能需求(比如上面的“支持多个数相加相乘”)之外,还有反馈、性能、互操作等等。不知已有的成熟语言项目是否有这方面的文档。
如果能用相对标准一致的描述方式对各编程语言进行需求分析,比较它们之间的异同也许会更方便,也可以对新语言的研发提供更全面的参考。wiki里 仅比较了特性:
我老板很想让我写
商业语言这方面文档公开的好像比较少。也许一些上世纪以委员会组织研发的语言会有更正式的需求分析文档。