用 C 写了一个 Racket 解释器，一个很小的功能子集

[haozhang]

常用的 form 都实现了，递归，闭包什么的，链接如下 https://github.com/Summerlve/Little-Racket

[guxingke]

@haozhang mal 有个 mal 语言的实现. 可以说是自举(self-hosted) .

[guxingke]

@haozhang racket 是个 lisp 方言.
mal 项目也是啊.

[haozhang]

@guxingke 多好玩呢....我说着 c 实现 racket，你给我来一套 mal 语言他娘自举....

[haozhang]

@guxingke 你来套 racket 自举么好了，来个 mal 自举什么玩意....

[haozhang]

为啥老是有人回复点莫名其妙的东西的，说着用勺子吃西瓜，他非得来个有人种了片南瓜你去瞧瞧，西瓜南瓜都是瓜....

[shangh]

牛

[shangh]

厉害~

[no1xsyzy]

@haozhang 小学语文：语义重复是语法错误
不过也有 “一颗是枣树，另一颗也是枣树” 这种

就像是你觉得没有 ./ “还得脑子拐道弯才意识到这不是标准库头文件”
但也有人看到 ./ “还得脑子拐道弯才意识到这不是标准库头文件”
我则是虽然一看就知道它不是标准库头文件，但还是会强迫症地想一遍 “这个东西是多余的” 并且再把 #include 语法从脑子里掏出来验证一遍，非常分散注意力。
另外，我不清楚 #include <./somelib> 是什么行为…… 小心导致不一致

[haozhang]

@no1xsyzy 所以我哪里写了...<./xxx>了，你找出来我改

[no1xsyzy]

@haozhang 我是说如果你哪天碰到一个别人写的 <./xxx>，结果你就当作是用户自定义库了，而实际上是找标准库的话会造成你读别人代码的混乱。
另外，根据 C 语言标准， #include "" 和 #include <> 如何寻找都是实现者来决定的：典型地，VC 的标准库和 gcc 的标准库在根本不同的，也不具有可兼容地进行指示的位置。所以说有可能导致某些编译器根本不认 "./xxx"，它根本不在本地目录找文件 "xxx" 而是在本地目录找文件 ".%2Fxxx" —— 结果找不到。

[haozhang]

@no1xsyzy 你说的对