语音识别静态解码和动态解码

转载

烟雨江南的秋 2024-12-27 18:15:11

文章标签 语音识别静态解码和动态解码对非静态成员的非法引用无法从静态上下文中引用非静态静态变量能动态获取嘛 文章分类 NLP 人工智能

我们经常会讨论到静态语言与动态语言的对比。

静态语言和动态语言的说法不太严谨，准确地说，是静态类型语言(static typing language)和动态类型语言(dynamic typing language)。

两者的主要区别：

静态类型语言，可以在编译期确定symbol的类型，比如C++/C#里，我们显式定义一个symbol的类型；比如一些函数式语言里，类型系统通过类型推导确定symbol的类型。
动态类型语言相反，运行时才知道各个symbol的类型。

静态类型语言，在编译期就可以获得充足的类型信息，因此可以在编译期做各种类型检查。因此，通常情况下，静态类型语言更适合大型工程，协同开发的效率很高。

我们写静态类型语言的时候，编译器或者插件会做很多工作，比如分析函数的signature，保证实现内和调用方形式参的绑定、数据在variable间的流动是类型一致的。

而动态类型语言，如果也想用于大型工程开发，会借鉴静态类型语言的一些机制或开发方式。

比如typescript，通过扩展类型系统、让程序员增加注解等方式，让js也具备了部分静态类型语言的能力。

Lua是游戏开发中常见的动态类型语言。

如果我们想把Lua也用于大型工程开发，也可以借鉴typescript的实现，扩展Lua的语言机制，让程序员多写一些类型注解，搞一个typelua出来。而且事实上，也已经有了类似的方案：

效果是这样：

local t : string = "Hello, world"

定义local完自己加个类型注解。

不仅如此，typedlua还加了不少类型推导/检查友好的语言机制，比如可空类型、组合类型等等。

但是，这种方案应用起来其实就是用一门像lua的方言，现有的lua工程无法无缝迁移。

而且，一门新的语言过于重量级，如果背后没有大公司支撑，让人只敢当做学术研究，不敢应用在工程中。

所以，今天小说君想聊一聊另一种更简单粗暴的方案——直接写个抽象解释器，在编译期做静态分析。

我们在工程中对lua静态分析的诉求，可以简单分为三个层次。

1.补全和信息显示。

敲一个字母，可以列个list告诉我们local或module内的其他符号。
可以查看module内定义的函数的signature。
可以定制查看一些预定义的静态注解数据。比如静态语言导出的供lua调用的接口；比如模块内显式定义的symbol的lua类型(函数或table)

2.类型检查。

一些错误检查，比如对一个nil做table access时报错；比如对一个非function类型的symbol做function call时报错；比如对非数值类型做数值运算时报错。
lua中一个函数的返回值是不确定的，通常我们开发规范要限定lua函数的各种情况返回值需要满足同一个约束。比如必须有返回值，必须有一个确定类型的返回值等。这时候，需要有对return statement的一致性检查。

3.智能提示。

我们在IDE中写静态类型代码，所有的提示要什么有什么。

比如：

可能递归的函数调用。
可能无法退出的循环迭代。
无法到达的代码。

等等。

一个完整的抽象解释器，写起来难度不亚于一个重新定义模型的lua虚拟机。

在本篇文章中，小说君仅就一个比较简单也比较常见的case来做简单的实现，希望能起到抛砖引玉的作用。

C#中，静态分析最常见的一个例子是Nullability Analysis。

比如：

语音识别静态解码和动态解码_语音识别静态解码和动态解码

这个静态分析功能，能提前查出很多比较低级的潜在bug，也是静态类型语言的优势之一。

我们今天就探讨下如何通过静态分析的方式，能判断出lua中的possible nil exception。

lua中，可能会抛nil exception的地方有两个：

对nil做table index。

local t = a.B

对nil做function call。

a()

某个对a的引用，a的Nullability有三种：

必然为nil。

if a thenelse    a()end

或

a = nila()

2.可能为nil。

比如从目前为止的env状态，无法判断a是否存在。

3.必然不为nil。

a()a()

其中，如果能执行到第二行，a必然不为nil。

还有其他带断言的情况：

if a then     a()end

只要我们的静态分析，可以检查并提示这几种情况，平时开发中大部分笔误写出的需要运行时甚至线上才能遇到的runtime nil exception就可以提前避免。

接下来，简单看下如何简单粗暴地实现一个抽象解释器，以及如何简单粗暴地支持一下前述的possible nil exception检查功能。

首先，我们需要一个parser。这个parser至少要提供如下功能：

可以完整支持要分析的语言的所有词法。
可以拿到节点关系完整的语法树。
可以遍历语法树。

随便从github选一个。不满足上述条件没有关系，只要挑的实现足够简单，我们很容易就可以补充。

小说君随便选了一个fork了过来，并且对细节做了些补充，欢迎大家取用。

parser的部分过于简单，我们看一下这个Visitor定义，就差不多能明白整个syntaxNode的设计了。

public interface ISyntaxVisitor {    void Visit(SyntaxVariable node);    void Visit(SyntaxNilLiteral node);    void Visit(SyntaxVarargsLiteral node);    void Visit(SyntaxBoolLiteral node);    void Visit(SyntaxUnaryOp node);    void Visit(SyntaxBinaryOp node);    void Visit(SyntaxStringLiteral node);    void Visit(SyntaxNumberLiteral node);    void Visit(SyntaxLuaJITLongLiteral node);    void Visit(SyntaxTableAccess node);    void Visit(SyntaxFunctionCall node);    void Visit(SyntaxTableConstructor node);    void Visit(SyntaxTableConstructor.Entry node);    void Visit(SyntaxBreak node);    void Visit(SyntaxReturn node);    void Visit(SyntaxBlock node);    void Visit(SyntaxConditionalBlock node);    void Visit(SyntaxIf node);    void Visit(SyntaxWhile node);    void Visit(SyntaxRepeat node);    void Visit(SyntaxFunctionDefinition node);    void Visit(SyntaxAssignment node);    void Visit(SyntaxNumericFor node);    void Visit(SyntaxGenericFor node);    void Visit(SyntaxLabel node);    void Visit(SyntaxGoTo node);}

拿到一个parse后的语法根节点，Visit，就能递归遍历这棵语法树的所有类型节点了。

parser帮我们拿到了语法树节点，接下来我们还需要拿到语义模型。

语法树中的所有语法节点都是描述性质的，只说明了这个位置有这么个语法节点，无法说明更多信息。

接下来还要做简单的语义分析。

首先，我们构建一个语义模型，把语法节点跟语义模型关联起来。

比如说，lua中，我们一个变量的类型可以是number、string、function、table等。一个对变量a的引用，语法树中对应的是一个SyntaxVariable节点。但是这个a目前有可能是什么值、如何被初始化、如何知道连续的两行代码引用的是不是同一个a，这些都属于语义信息，无法直接从语法树中获取到。

静态语言中，构建语义模型，主要的工作是构造一个符号表，然后我们可以通过语法树节点去查找关联的符号。

一些基本的符号：

FunctionSymbol	具体的函数定义信息
GlobalSymbol	对_G的符号引用
IteratorSymbol	一种特殊的VariableSymbol，for语句中的迭代器变量
LocalSymbol	常见的VariableSymbol，一个local变量
ParameterSymbol	FunctionSymbol中的形参符号实体
TableElementSymbol	一次table access，属于一种annotation

然后是符号的作用域。

lua虽然是个嵌入式的脚本语言，但是在符号绑定上也有一定程度的静态语言特征。比如这个例子：

function f()    print(a)enda = "global"local a = "test"f()$lua main.luaglobal

local a = "test"function f()    print(a)endf()$lua main.luatest

几点结论：

第一段代码第2行的a，绑定到了_G的a。
第二段代码第4行的a，绑定到了外层scope的local a。
function definition内部的scope，可以有限引用外部scope的symbol。

按照这些特征，我们增加一个作用域结构即可。

function f内部，如果需要获取variable a的symbol，会先查当前scope内部的符号表，查不到的话查外层符号表，直到变为一个对_G的引用(GlobalSymbol)。

语义模型的工作就差不多这样了。

最终我们产出的是一个接口：根据语法树中的任意节点，获取节点关联的Symbol。

以上就是做possible nil exception check的准备工作。

接下来进入正题。

如果说，动态类型语言做静态分析的难题在于，编译期我们无法获取足够的信息。那么，只要我们编译期有选择地「执行」一遍代码，就能获取到更多的信息。

有选择地「执行」，就是指抽象解释。

local a = {}

运行完这样一行代码，我们不需要知道a具体维护了一个什么值。

我们只需要知道，执行完这行代码，a一定是一个非nil值；
深入定义的话，我们知道，执行完这行代码，a是一个没有任何字段定义的table。

抽象执行中抽象的含义，在分支结构中更容易理解。

local b = {}if a then    a()    b = nilelse    a()endb()

语音识别静态解码和动态解码_无法从静态上下文中引用非静态_02

如果要正确分析block1~3，我们要借助控制流分析的方法；但是分析block4的时候，我们又无法用控制流分析。

先捋一捋流程：

每个block执行完毕都会产出一组predicate。比如block2的产出是a必然不为nil+b必然为nil。
每个block都有一组dominators(tips：block的dominator表示，如果要执行到某个block，则一定执行过该block的dominator)，block内的分析，需要依赖dominator产出的predicate，条件结构中的cond是一种特殊的predicate，会自动附加到该条件对应的block中。比如block2的预定义predicate就有a~=nil。
block4之前，出现了一个merge point。由于具体的分支结构是运行时才能确定的，因此分析block4的时候要判定b为可能nil。

从分析可以看出来，首先要做的是，把一段代码拆分成不同的block，获取block间的dominate关系。

逻辑比较简单，一个scope内的statements，非分支结构的连续的语句各自合并，分支结构节点单独拆分成一组block。

接下来，开始按顺序执行block。

lua中的block分为两类：

最外层scope的block，就是一个lua文件里最外层的语句。
函数定义内部的block。

第一类很容易处理，按顺序执行就行了。

需要注意的是，由于涉及到函数的跳转和分支结构，因此需要维护在immutable结构中，每次跳转或进不同分支，都要拷贝状态，控制收回时再回溯到初始的状态。

第二类处理起来比较复杂，每个函数定义的内部block可能会执行多次。

第一次，仅作为函数定义处理。这次处理，不对执行环境做任何假设，只关注local和形参在流程分析中可能产生的nil exception，其他对_G的symbol引用都处于一种待决议状态。
函数每次被调用，都会额外处理一次。被调用的处理，需要带上当前的抽象解释上下文。除了第一次的分析内容之外，还要填充待决议的symbol，进行一次完整分析。

执行一个block的逻辑就是简化版的执行一个block组。

注意这样几点：

block内的statements，可以理解为同scope的连续block，每个block一个statement。
每个statement的执行，同样要依赖前面的predicate，产生新的predicate。

local bprint(b.B)print(b.B)

静态类型语言的分析中，第3行会报possible nil exception，而第4行不会。

我们在分析时同样，第3行会产出一个b必然不为nil的predicate，因此第4行不会报possible nil exception。

3.statement内，主要关注table index和function call两种操作。如果对某个symbol做table index或function call时，并没有查到前置的该symbol不为nil的predicate，那么这里就需要报一个possible nil exception。

如前所述，整体的逻辑很直接，实现起来简单粗暴。

当然，篇幅所限，有些议题还没有讨论到。有兴趣的小伙伴可以边实现边和小说君探讨。

比如：