前阵子向大家分享了我写的插件https://marketplace.visualstudio.com/items?itemName=CamileSing.flink-sql，最近梳理了我之前的学习相关知识时的笔记，希望能够帮到对这一块实现感兴趣的同学。

1. TypeScirpt

开发 VS Code，可以选择使用了 TypeScript or JavaScript。虽然我没学过 TypeScript，但是我还是选择了它。我想起大学工作室的时候，身边有小伙伴就特别喜欢 JavaScript 这种写起来很快的语言，但是我却更喜欢 Java 这种语言。因为有些时候我根本不知道 JavaScript 里的一些变量的值到底是什么。

TS 在官网是用一句话描述了它TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale。一段时间用下来，发现 TS 真香，我本身接触的语言也不算少，所以上手很快。而且它的类型系统非常强大，让我非常有好感。

这个语言让我比较印象深刻的是，它不仅设置了类似 Java 中 Object 的 Unknown，还有所有类型子类的 Never 类型，用来代表其永远不会发生，比如：

function foo(x: string | number): boolean {  if (typeof x === 'string') {    return true;  } else if (typeof x === 'number') {    return false;  }
  // 如果不是一个 never 类型，这会报错：  // - 不是所有条件都有返回值 （严格模式下）  // - 或者检查到无法访问的代码  // 但是由于 TypeScript 理解 `fail` 函数返回为 `never` 类型  // 它可以让你调用它，因为你可能会在运行时用它来做安全或者详细的检查。  return fail('Unexhaustive');}
function fail(message: string): never {  throw new Error(message);}

另外就是对于范型的支持也很有意思，上面这个函数签名可以写出foo(x: string | number)这样的写法。对于范型支持的更好意味着可以让程序员更好的去做抽象。

在学习 TypeScript 的时候还接触到了一本书，叫做《编程与类型系统》，被一些网友戏称“一周入门 TypeScript”。整体内容还是比较不错的，讲到了类型系统来自于数学中的范畴论，以及类型系统的优点：类型的主要优点在于正确性、不可变性、封装、可组合性和可读性。这 5 种优点是优秀的软件设计和行为的根本特性。系统中总有出现混乱或者无序状态的倾向，而上述特性则起到抗衡这种倾向的作用。以此展开聊 TypeScript 的一些语法，以及对比 JavaScript，TS 做了哪些有用的改进。

2. 错误检测能力：词法、语法分析

插件的错误检测能力，其实是基于词法、语法分析实现的。我们先来解释一下名词：

• 词法分析：一个个词去找，有些情况下需要多看一个乃至多几个个单词才能确定这个词是哪个类型的 token（这种行为在编译器里面叫 peek）。

• 语法分析：根据已有 token 序列，分析每一行代码是什么属于什么语句类型——也是一个个 token 进来分析，有些情况下需要 peek 下一个乃至下下个单词才能确定。

这块其实是编译原理的一部分，属于前端编译部分，并未涉及后端编译。见：https://github.com/camilesing/Flink-SQL-Helper-VSCode/blob/main/src/extension.ts中的

// 使用生成的词法分析器和解析器进行语法检查const inputStream = new ANTLRInputStream(event.getText());//词法解析const lexer = new FlinkSQLLexer(inputStream);const tokenStream = new CommonTokenStream(lexer);//语法解析const parser = new FlinkSQLParser(tokenStream);parser.removeErrorListeners();parser.addErrorListener({  syntaxError: (recognizer: Recognizer<any, any>, offendingSymbol: any, line: number, charPositionInLine: number, msg: string, e: RecognitionException | undefined): void => {    vscode.window.showErrorMessage("Parser flink sql error. line: " + line + " position: " + charPositionInLine + " msg: " + msg);  },})parser.compileParseTreePattern// 解析文件内容并获取语法树const parseTree = parser.program();

写这块代码我用到了 Antlr4-TS 这个库。我根据一些 Antlr4 的语法规则，生成了对应的代码，并将输入内容丢进这些类，让它们吐出结果。在了解 Antlr 相关的语法规则时，让我特别震撼——类似于刚毕业一年时接触到 DSL 时的震撼。通过一系列规则的描述，竟然可以生产如此复杂、繁多的代码，巨幅解放生产力。这些规则是一种很美又具有实际价值的抽象。

那让我们抛开 Antlr 这个框架的能力，如果去手写一个词法、语法分析的实现，该怎么做呢？

在编程语言里，一般会有保留字和标识符的概念。保留字就是这个语言的关键字，比如 SQL 中的 select，Java 中的 int 等等，标识符就是你用于命名的文字。比如public class Person中的 Person，select f1 as f1_v2 from t1 中的 f1,f1_v2,t1。

再扩展一下概念，我们以int a=1;这样一段代码为例子，int 是关键字，a 是标识符，=是操作符，;是符号（结束符）。搞清楚哪些词属于什么类型，这就是词法解析器要做的事。那怎么做呢？最简单的方法其实就是按照一定规则（比如 A-Za-z$）一个个去读取，比如读到 i 的时候，它要去看后面是不是结束符或者空格，也就上文提到的的 peek，如果不为空，就要继续往后读，直到读到空格或者结束符。那么读取出来是个 int，就知道这是个关键字。

伪代码如下：

循环读取字符  case 空白字符    处理，并继续循环  case 行结束符    处理，并继续循环  case A-Za-z$_    调用scanIden()识别标识符和关键字，并结束循环  case 0之后是X或x，或者1-9    调用scanNumber()识别数字，并结束循环     case , ; ( ) [ ]等字符    返回代表这些符号的Token，并结束循环  case isSpectial()，也就是% * + - | 等特殊字符    调用scanOperator()识别操作符  ...    

这下我们知道了int a=1;在词法解析器看来其实就是关键字（类型） 标识符 操作符 数字 结束符。这样的写法其实是符合 Java 的语法规则的。反过来说：int int=1;是能够通过词法分析的，但是无法通过语法分析，因为关键字（类型） 关键字（类型） 操作符 数字 结束符是不符合 Java 的语法定义的。

这个时候可能会有人问，为啥要有词法分析这一层？都放到语法分析这一层也是可以做的啊。可以做，但会很复杂。而且一般软件工程中会都做分层，避免外面的变动影响到里面的核心逻辑。 举个例子：后续 Java 新增了一个类型，如果词法分析、语法分析是拆开的，那么只要改词法分析层的一些代码就行了，语法分析不用。但是如果没有词法分析这一层，语法分析的代码会有很多，而且一点点改动就很容易影响到这一层。

在此之后就会生成语法树。后续我打算做一些基于语法树的分析，Antlr 提供了两种读语法节点的方式，一种是 Vistor，一种是 Listeners。前者意味着你可以主动的去遍历一些节点，而后者就像注册了钩子，Antlr 遍历到这里的时候会主动“喊”你。

// 创建访问器实例并访问语法树，以获取语法错误和警告const visitor = new MyFlinkSQLVisitor();visitor.visit(parseTree);const errors = visitor.getErrors();

编译器其实分前端编译部分和后端编译部分的。语义分析也是在前端，在语义分析阶段，其实是可以定义一些规则去做优化的。

编译器的后端，主要是负责语法树到目标代码（平台无关），到平台有关代码——比如，同一段源代码生成的 x86 体系下的可执行程序和 MIPS 体系下的可执行程序，其运行时结构会有较大的区别，这种区别会体现在目标代码上。如果一步到位由语法树转换为目标代码，就需要为每种 CPU 去写一套完全独立的后端。为了避免这种情况以及便于优化，于是在语法树和包含机器特征的目标代码之间建立了一个中间结构，这样就能更加方便地将语法树转换为适合不同 CPU 的目标代码，这是设计中间结构的最初目的。高端 gimple、低端 gimple、cfg、ssa、RTL（Register Transfer Language）就是这样的中间结构。这块没有什么实际的业务场景可以接触，所以就没有深入去看了。

3.小结

业余开发这款插件，的确花了我很多时间。现在想来还是很值得的——在这里面学到了很多，而且还把自己想做的东西做出来了。后续迭代中，有新的学习笔记或感悟，我也会整理上来，分享给大家。