(1)LUA源码阅读(四)

面向非专业程序员的语言，最好能在编译时检查函数签名(匹配参数名称，参数个数和其参数类型）。而C封装给lua的函数，得要传入参数、实际运行一遍，才能知道运行路径上是否有错误(对于那些运行不到的分支路径上的，函数调用错误还是无法发现)。因此，需要考虑改造lua的前端，甚至可以考虑把它从动态类型语言给改成类C的语法，而保留其VM部分。
llex.c负责词法解析的函数，400多行。lparser.c应该是负责语法和语义的，1300多行。粗看了下，代码结构还是比较清晰的。

sourceforge上的这个项目CLUE：http://sourceforge.net/projects/cluecc/
有点像我们想要的c解释器，c语言做前端，后端可编译成各种语言(lua, java, lisp,perl....)。clue本身带了点实验性，并不完备，最近的一次更新在2008年。
它的词法和语法用的是sparse,linux下的一个C语义分析器，实际用于检查代码包括linux下的源代码，应该来说相对比较成熟,但其支持了不少GCC的特性，可能相对比较复杂。通过调用sparse_initialize将其转换成一个symbol_list。
cluecc的源代码结构不复杂，所有关键的函数和结构都定义在global.h中。结构codegenerator来表示代码生成的后端，大部分成员变量是实现语言基本逻辑的函数指针，由各个语言后端去实现各自的codegenerator(cg_lua, cg_java, cg_javascript...)。查看了cg_lua.c文件,基本是利用格式化打印语句转成可读的lua脚本语句，主要是花了不少代码在函数转化和循环分支语句之类的转换上面。

比较查看了不少C语言的前端解析，我们理想的目标是：a. 语法支持范围更小一点（简练表达业务逻辑即可，而不需要涉及系统方面的）; b.项目规模小，代码可读性强（因为需要理解修改）; c. 有相对完备的语法错误检查和报告。
PCC用的是lex,yacc，后端也很强，各种平台。
OTCC（Obfuscated Tiny CCompiler），目前见过代码量最小的了。它本身就是为了参加一个要求能编译自身的最小编译器比赛而做的。看了下主要代码，是边parse边直接生成机器码了。这是不是我们想要的样子呢，类C语言直接生成lua的bytecode. OTCC的作者另外有一个对 ISO C支持更完整的项目TCC。
google开源项目picoc，也很小，picoc的核心代码3000多行。它最初就是设计起来做为一种脚本语言,并不支持完整的ISOC标准，但基本的都有。
LCC,又一个产品级别的C语言编译器，有基于其上的lcc-win32等一整套的开发工具，包括调试。