@HuasLeung 光明顶草

@Kilerd 我同意语法设计的一致性是重要的，但我不同意只是一眼看上去的风格上的一致才重要。
相反，你指出的设计上缺乏的一致性，我认为是一个比较次要的方面，次要到如果用我的立场来考虑甚至可以无所谓这里的一致性——因为已经到处都够不一致了。
在展开解释之前，为了避免理解困难鸡同鸭讲，首先，我先解释一下我为什么觉得 LZ 这样设计的语法不好——因为比较复杂。
这个复杂并不是单独语法意义上的，而是牵涉到整个语言的语义设计和可用性上的。这样说过于抽象，我就说一下什么是我认为足够好的吧：能自然地接近 AST，允许自动获得同像性(homoiconicity) 的语法。
进一步，parse 这种语法的实现也是从简的，比如 LL(1)都能搞定。麻烦的东西全扔给语义去处理。
从我的角度来看，没有这样的性质的语法，就已经不够“一致”。
如果我要人肉 parse 这样的不够一致的语法，就必须参考具体的 BNF 或者其它表示，而不是仅记忆一个整体的只依赖词法设计上的文法规则（这样的规则的字典是字符集合，而不是记号集合），才能做到严格准确。
虽然有时候并不严格的准确也可以凑合用甚至还可能发现一些经验规则，但这种特例是破坏各种意义上的一致性的，让我觉得很不舒服；这对实现也不友好（基本没法用）。这种不严格可能非常微妙以至于大部分人都容易错误地忽略。举个例子，有许多人认为 C 的复杂声明可以用所谓“右左右左”的“黄金法则”来 parse，但是实际上真正看清楚 C 的声明符(declarator) 语法的会知道，这样做其实是不靠谱的——因为这隐含了“知道哪个标识符是要被声明的”这个不靠谱的前提。C 的 parser 也不能这样地实现对。
现在再回过头来讨论你说的“一致”。我的观点是，已经能肯定，这样的语法不得不看具体语法规则才能 parse 那么麻烦了，再去假定如何能在细节上“一致”，是没多大实际意义的。
因为，这样硬编码的整套语法规则其实并没有余地正式保证你所谓的一致，所谓一致全是君子协定。于是，就算这里改成符合你期望的一致了，万一哪里突然又冒出一个特例为违反你指望的这种一致呢？再发明不同的乱七八糟的“黄金法则”然后来 trial and error，或者干脆像 C++的常见套路一样做 speculative parse，然后通过语义分析排除掉错误的 parse 路径？
……这对人类读者来讲也太扯了。（天下人苦 C-like 久矣……）
上面说的是语法的方面。你提的一致还提到了一些语义上的东西，例如类型推断。不过同样我不觉得这里的一致性有你说的这般重要。因为，只要不限制 spec 的长度，写出强行规定成一致的语义规则的余地实在是太大了。你觉得不一致？很好，那只是你没发现……
所以，没看到 lang spec 之前，我不同意你的不一致的理由。反过来，看到 spec 之后，倒是可能容易判断这样的设计不只是语法，在语义上也明显不必要地复杂了。

@Qiaogui
你搞错了不少东西，不过好像也不是很难纠正。（只是错的地方有些让我意外。）
首先，设计语言是专业的领域，有门槛，但大部分门槛跟程序员的经验的确不搭。
（比如，确实也不能指望大部分程序员搞清楚什么东西才能够得上是语言的 spec。）
不清楚怎么写现有语言的代码，确实不碍着设计语言。大致上你能清楚你设计出来的东西怎么用即可。
但是，自己能实现会远远更省事，并且会避免一些实现手段上的认知偏差。我认为你已经在吃这个亏了（比如说，不够清楚 LLVM 为什么不值得用），要让别人帮忙减小这样的问题并不现实。
还有个更根本的原因是，对一般意义的通用语言来说，区分元语言和对象语言是不必要的，因此不了解实现又没有能力自己发明整套新方法代替现有实现技术的话，势必无法得到你想要的设计。
只不过不止是你，劝诫你需要自己了解如何实现的各位好像也没都理解这个。
其次，语言不止是表达思想的工具。如果要强调通用语言，一定意义上，语言就是思想本身。你对语言的想法，不止是通过 spec （元语言），也会通过代码传染到你用语言表示的目的上。
即便放弃这点，style 这种东西也不会自动不存在。这也是形成 paradigm 的主要理由之一。
（搞 AI 的管这个叫符号主义学派，但在 PL 领域没有类似搞 AI 的其它学派的备胎能指望，所以回避不了。）
第三，程序员觉得所谓语言的友好大部分是错觉：社区友好 /用户友好跟设计出来的语言友好是两回事。
（比如说，随便拿坨实用的代码自己人肉解释一下然后问问自己有没有解释对，底气在哪，就知道大概多不友好了。）
作为语言的设计者不要落入这个陷阱。特别是你学会了了解“友好”，却没学会熟练编码这种能体现这样的片面“友好”的最主要场景的话，那么基本只剩错觉了。
第四，你指望别人整理，那就不是自己设计，是甲方了……这样，穷真的是没救的。

至于我自己，早就有实现能用的设计了，就是想化缘拉点苦力做点偏体力的活……
只是我发现 LtU 上人平均认知在准确理解需求的阅历和能力上尚且远远不足，刻意在这边找就是姜太公钓鱼随缘罢了。

@learnshare 你给的链接里出了个奇怪的东西……
Rust 一直没有成型的 spec。那个 reference 虽然被迫代替 spec 来用，但是根本不足以判定 conformance，也没提多少 design rationale。比起设计文档更接近用户手册。

@Kilerd 不要强人所难，SICP 确实不教这种玩意儿。
我同意这语法设计的不咋地（另外，如果看的是新版 SICP，会出现各种奇葩口味也不奇怪）。不过，这跟“不一致”有什么关系？
你这里有一个显然的技术性的错误：没拿到形式文法（ LZ 是在 89L 发的），怎么知道“不一致”？

var int q = 1, w = 2
int i = 1

没看 LZ 的文档，花 1 秒钟就能反应过来，很容易规约成类似这样的：

var_opt type-id (identifier = initializer)(, identifier = initializer)*

如果这种文法都算所谓的不一致，按你的逻辑，C++之类的大多数 ALGOL-like 语言都是妥妥的 toy language 了。或者你拿你的作业跟这些语言比比看看先进在哪？（虽然老实说，要比这些语言更烂才是更难的……）

（看了下 LZ 的文档，比这个是麻烦多了。）

@halou12 这个明确说了创建的是 DSL，跟 LZ 目的不搭（而且因为很多原因……这货显然没什么牌面）。
@Mutoo 王垠这 dd 就别指望了吧，看他的 publication，非得说肚子里的墨水的话，这人本质上更接近他自己鄙视的“低于设计语言的”“搞编译器的”人士。反正我是没发现他搞出过半个 model （不管是 calculi 还是 abstract machine 还是其它什么乱七八糟的。）
像 Rust 为什么搞出 lifetime，CheckedException 失败在哪，其实都是很浅显的东西，只不过理由比较偏工程需求而已。混了那么多年还不能一眼看清楚，这应该不是工程实践不足，还是天赋问题了。

@CSM 指针这概念还真没几个人理解得清楚了，基本上脑子正常的人理解了就不会尝试塞进高级语言里面去了（塞 machine-oriented ISA 里面勉勉强强还可以说得通，然而纠结是否钦定 flat address space 之类的笑话还是敬谢不敏）。

@rainmakeroly 跑个题，虽然你书的队，就设计上的本事，GvR 和那坨巴西人还真是不够看的：前者是连 proper tail recursion 都不知道的程度，后者是 EWD831 都理解不了的水平。虽然这不妨碍 py 和 lua 在各种偶然下 dssq，但有原型能力能让屑流行起来，也是一种工程灾难。
@Qiaogui 常识水平也不行，你这姿势离历史的行程差太远了。
LLVM 虽然是屑，但是“不如 bison 和 flex ”…… emm，你确定你清楚这些玩意儿是干什么了的吗？
还有你喜欢辣么多辣鸡有用么。。。就设计语言的工作，首要产出自然不是解释器和编译器之类的实现，而是 spec，但是你似乎连这点都不怎么清楚。如果清楚目标的话，Scheme 是暴打剩下几个几条街的（如果不算开发过程撕逼的话；不过其它几个这方面也不好看）。

看标题以为是能随便甩手投资几百 w 的那种，万事俱备只差程序员了。
结果嘛……
LZ 你这技能明显没点对啊，你哪来的自信以为你发明的别人就没搞过？还是先学会怎么写需求文档同时 diss 别人吧，否则还不是老调重弹了无新意嘛。给个示范：
https://github.com/FrankHB/pl-docs/blob/master/en-US/calling-for-language-features.md

@lihongjie0209 用 Windows 是因为有些东西确实只能用 Windows，而 Linux 上 wine 出来不靠谱。用 Windows+WSL 大部分情况下比其它配置都省事，而且至少跑 Linux 的 userland 应用不大容易出现像 wine 这样卡翔或者兼容得莫名其妙的情况，毕竟兼容的层次没法比。而理论上能有对应兼容性的 Linux 兼容内核（ Longene ）并不是原生的 Linux 内核项目，而且坑了好多年了。
要是搞 Linux 内核模块或者 systemd 什么的，那倒是真没办法，要么 Windows+虚拟机 Linux，要么 Linux+虚拟机 Windows，要么干脆都真机，但总之都比上面的更麻烦，老实认栽了。

@a1528026364 老实学习 simple English。我不觉得现在的中文资料的翻译质量有让多少你踩更少坑的机会。（“堆栈”？什么鬼？）
@Dram001 谭浩强用的原生环境还真的未必好烫烫烫……
@ochatokori 凭实力花钱买的，还需要学完？（ G 胖.jpg

这种 trivial 的信息，放在 repo 里，不亦乐乎？
https://github.com/komeiji-satori/Dress

@lihongjie0209 WSL 的 CLI 几乎是一开始就能暴打 ps1，更不用说逗比 cmd 了。近期的 WSL 已经接近 Linux 的原生 userland 支持了，我遇到过就差一坨 SysV API 和 i686 兼容性问题，大部分情况踩不到。不考虑高分屏甚至某些 GUI 程序都比原生 Win32 靠谱。而且某些应用同个机器上都能看出 Win32 性能坑了几倍了。

@trait C 艹里抄了一大坨还叫没有引入新特性……
C11 到 C17 之间确实是挺咸鱼的，不过之后嘛……
http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm
虽然不买书原则上也是对的，因为书的作者基本都没跟进就是了，连实现都没怎么支持嘛（ MSVC 到现在还不支持全 C99 呢，连 C++11 的预处理器一并跟着遭殃，不过好歹终于在 2017 支持 C++98 的 ADL 了也不多黑了……）

免费权威资源一大把还看不过来，买书？
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
https://www.quora.com/What-are-the-differences-between-the-n1570-final-draft-and-the-published-ISO-IEC-9899-2011 （有人买了给我确认过，属实，其它的只有 reference 的区别。）
（ C17 倒是好像要加密访问，不过反正也没多少区别了……）
https://docs.oracle.com/javase/specs/jls/se11/jls11.pdf
https://docs.oracle.com/javase/specs/jvms/se11/jvms11.pdf

@anguiao 这是错的。
首先，如果基于修改的代码的作品不公开发布(publish)，明确不符合 GPL 的条件。我所知的 GPL 依赖的版权法也不要求对未发布的作品进行保护，而决定是否发布作品原则上是衍生作品作者的著作人身权，基本上是版权法明确指定的。
其次，GPL 对仅使用 API 的衍生作品也生效，不管你是不是看了实现。

@anguiao 这是错的。
首先，如果基于修改的代码的作品不公开发布(publish)，明确不符合 GPL 的条件。我所知的 GPL 依赖的版权法也不要求对未发布的作品进行保护，而是否发布作品原则上是衍生作品作者的著作人身权。
其次，GPL 对仅使用 API 的衍生作品也生效，不管你是不是看了实现。

IANAL，不过很明显技术上不允许。因为你提供的形式在技术上没法有效保证属于 GPLv3 定义的 conveying，所以不足以证明你取得了合法的授权。

https://www.gnu.org/licenses/gpl-3.0.en.html

...

To “ convey ” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

...

6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

...

如果你非要对着干，我倒是知道个阴招：只在线提供源码，限速到几个 B/s。
不过，我还记得 RMS 有另外的可能对付这个的补充解释，不过没经过案例考验，可能很大程度上取决于管辖如何推定你是否具有侵权的恶意。

@NetCobra 标准操作。
https://en.wikipedia.org/wiki/Clean_room_design
https://en.wikipedia.org/wiki/Chinese_wall#Computer_science