@youxiachai 你要往编译原理上靠那也是野鸡知识。
这个（最表面上层次上的）问题说穿了很简单：形式参数作为绑定变量的名称，它对语言的语义无关紧要，正经的语言设计一开始就没有把它设计为可以让用户可靠地进行依赖的接口特性，而只是实现细节。
更进一步的原理是，支持反射形式参数名破坏 alpha renaming 保证的语义等价性——保证重写规则中仅仅替换形式参数名，只要不冲突，就能保持语言的语义不变。
这背后的原则是变量名的含义应对确定如何计算的语义规则不透明，语言设计原则上不需要干涉用户怎么命名变量，这样用户可以按需自己选择命名约定以满足不同的需求。（这也是一票重构工具的基础。）
这在工程上给语言的设计者也带来了很大的方便——至少不需要就自然语言的含义纠结了，也不需要非得把命名规则这样零碎的东西写到语言的规格描述里才能用，就算写进去了也原则上不需要和改动语言特性冲突。
（至于某些 PL 强迫用户使用 camelCase 之类的瓦釜雷鸣，说白了这来自特定自然语言内部的缺陷，跟 PL 的设计原则上本应无关——比如要是一开始用中文就连纠结 case 的基础都没有了——虽然中文有另外的破事。如何纵容自然语言的旮旯污染到 PL 设计上这就是另一回事了。）
所以正经的语言不管编译不编译，都不会去支持这样的特性。方便编译优化，是另一个顺带的副作用罢了。
当然，不是所有的简单明显语义等价性都该教条主义地被保留，例如破坏 eta equivalence 允许函数调用带有可观察的副作用，很大程度上是可取的。但是破坏 alpha renaming 并没什么这样显然的好处还会添乱，得不偿失。
但造成 LZ 问题的不只是不理解为什么语言需要这样设计。更深层次的问题是，为什么需要反射来提取这样的信息？
说白了也不复杂——语言没提供足够的机制（例如通用的 AST 接口）让用户自然地以一致的方式选取如何保留源代码中的信息，以至于表面看起来不复杂的需求突然就土法炼钢了。
也不是特地需要婊 Java （几乎所有静态语言都有类似的毛病），但 Java 这种典型钦定编译 phase 没 homoiconicity 翻译时元编程又叒鸡的静态语言，就是这种先天不足的典型。所以没特地适应如何避免这种缺陷的用户遇到这类问题，以及一般的解决方案只能绥靖，就见怪不怪了。

挂 BOINC。
不过，像我用 SB2 之类的……
……算了，房间里多放台机器开 BOINC、、、

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
随机点进去都能批判一番基本就差不多了。
项目？写得完？

草、贴多了，以上最后一节请无视……

@GeruzoniAnsasu 还有一个无视历史行程的流毒甚广的基本理解偏差单独挑出来说。
形式参数的“形式”跟“类型”无关。使用显式类型的语言才在函数的类型声明顺带形式参数的声明，因为决定函数类型的类型构造器（→）要求已知参数类型，不在函数声明中提供，还是要在其它位置明确，才可能允许函数类型检查。
这个节点里照日常使用，姑且都能算是这样的语言，但严格讲，C 就不强制——函数原型声明是可选的，不要求总是具有函数参数类型：
比如 int main() ，你拿 GCC 去调用 main(什么乱七八糟) 可能都过得去，Clang 倒是仍然会检查，但也不同于 int main(void) ；
其它用法参见 K&R C 古董代码。
不使用显式类型的语言里函数的绑定变量一般意义下也叫做形式参数，只不过“参数(parameter)”在某些情况有其它含义（ Lisp 方言使用参数作为动态作用域的变量，纯函数式语言使用参数表示类似 C++的模板类型参数的参数多态的类型变量），所以不怎么单独提出来说而已。这样的函数形式参数的所谓类型，可能是不需要明确把类型写出来而确定的（如 Haskell 这样默认就鼓励使用类型推断(type inference) 确定的语言），也可能因为变量不存在确定的类型而根本不存在（如 Scheme 这样使用清单类型(manifest typing) 的语言）。

最后回答 LZ 的问题。一般地，使用实际参数(actual argument) 初始化函数的形式参数(formal parameter) ，在函数被调用——带有作为操作符的函数以及函数的实际参数的后置表达式被求值时——发生。
对这个节点讨论的语言，函数这个特性（排除宏这种更一般意义上的“函数”）对实际参数的求值总是使用原始的应用序(applicative order) ，即函数的实际参数先于函数体被求值（但注意，不同实际参数之间没有“最左”的保证），因此（借用 C++11 和 C11 照抄 C++11 的概念）初始化总是后序于(sequenced after) 函数调用的实际参数求值之后。

一般地，函数的形式参数(formal parameter) 在

@mutalisk 放寄存器了就没人权了？
@GeruzoniAnsasu 扯蛋。
形式参数在 C/C++/Obj-C 的抽象机语义里就是特殊的局部对象 /变量，你调用了还能跳过初始化？行，试试证明不初始化不改变语义？
所谓“形式”的含义，是指不同调用实例中的实际参数能具有一对多的对应关系。不管是使用作为所谓实际参数的表达式进行绑定变量的替换或者利用活动记录的存储的代换，对“形式”不形式而言，说穿了都是实现。没有因为变量替换（更确切地，capture-avoiding substitution ）在历史上更早就更抽象的道理；况且这个节点里的语言全部不使用变量替换，而在语义上直接要求非一等的环境（局部变量的活动记录帧）外加允许一些 as-if rule （如 C++引用不要求占用存储）的变换。
如果无视这些要求，按原始的 λ 演算的语义，你都可以说这里要求的替换是无副作用的，替换的操作不存在影响可观察行为的计算作用，直接把初始化的概念取消得了。

我自己用的……demo：
https://github.com/FrankHB/YSLib/tree/master/YDE
但是现阶段没提供工具基本比 Qt 蛋疼（虽然疼的地方不一样）。
其实 Qt 也就是那么几个 dll 嘛，，，

你这是只打算用 Win32 ？一次性方案？还不如自己日 UpdateLayeredWindow 了。

看来又是个 ALGOL-like 语言学残的……补习一下历史罢。
世界上本来就没什么正经的函数(function) ，先是在 1930 年代 A.Church 提出 λ 演算里用于替换绑定变量为其它表达式的 λ 抽象以及把 λ 抽象绑定到一个名称作为变量的用法，后是 1950 年代 J.McCarthy 明确用这样的方法，来实现的一般意义上的所谓的函数。这样，λ 抽象实质上就是所谓的匿名函数(anonymous) 。（在原始的 λ 演算中，这些匿名函数都是所谓的纯函数(pure function) ，之后有另外的扩展，但这个意义上正经地搞是在 1970 年代以后的事。）
之后（从 1950 年代末开始），一坨不上道的 ALGOL-like 语言把函数弱化成过程(procedure) 乃至子例程(subroutine) 偷换概念，让函数总是总是具有所谓的函数名，先接触这类语言入门的用户就被念歪经的设计整残了；如 Java 之流的更叒鸡的语言把过程继续阉割，去掉了所谓的自由函数(free function) ，叠床架屋依附于所谓的对象（原本对象就跟类的实例无关，考虑到 Java 照抄某些语言的历史，这里是牵强附会）之上，搞出什么方法(method) ，数典忘祖；于是用这样的语言入门的用户更加不会正常的思维方式了。现在一坨语言重新引入 lambda 表达式来表达 λ 抽象，说到底不过是矫治习惯不正常的理解困难的设计的症状，要求端正视听罢了——只不过很遗憾，因为兼容和历史包袱，已有的半残的“函数”或者更残废的“方法”的语法还是被保留，以至于理解起来更容易迷糊和浪费时间。
（至于在子例程以外的函数的其它实现，如 coroutine 和 continuation 也是很早的支线，比 Java 资格老大概 30 年，这里按下不表，等 Java 之流的语言先赶上再说。）

当然，不够正经的、歧义满天飞的所谓函数数学早已有之，历史上翻来覆去倒腾了几百年也没个谱，后来才发现严格意义上可以是一回事（例如，以所谓可计算函数(computable function) 作为模型)： https://en.wikipedia.org/wiki/History_of_the_function_concept
和这样的模型比较接近的是一般大学高等数学会教你的基于 Cartesian product 模型化的映射(map) 。数学中更常见的所谓的“函数”和泛函(functional) 都是其缩水版，要求值域是实数，这在日常应用中往往是多余的限制；高中用的“函数”的 Dirchlet 定义，更是连定义域都锁死了，也不讲上域(codomain) ；除了数理逻辑讨论的一些概念，对语法和语义的分割也聊胜于无。所以对理解关心如何用代码的描述和解决计算问题的角度来说，用这些不够严格的传统数学概念，大多讲了白讲。
现代编程语言常规支持表达的某一类偏可计算函数(partial computable function)，除了不可解度（不超越图灵完备）以外，比映射能实现的计算作用(computational effect) 更强，例如允许副作用(side effect) ，也不要求是全函数(totality) 保证确定性终止。（倒是某些 FP 语言会别有用心地妄想把其中某几个特性干掉给阉回去。） Java 之流虽然叒鸡，但是比起来还算是比较正经的了。

@zunceng Phabricator 我一直有计划要上的，主要是看 BitBucket 都要下线 hg 了，找公用的 hosting site 还不如自己内部直接维护全套的。不过这玩意儿整个部署起来还是麻烦，而且也没法解决 VCS 内部不能感知 diff 语义的更根本的问题。可能总有一天这部分也得自己造轮子了。

@shmilypeter 不需要，路灯还要基建成本，抽 100%所得税就行了。

偶尔就算了……不过我还看到有单休周末固定开会+团建的，就比较费解了。

印象中比较有存在感的就是个 MSRA，不过（几年前）据说很坑：
http://m.newsmth.net/article/Microsoft/60544?p=1