[Erlang-0010][News]OTP 技术委员会 - 影响R16的决策 （OTP Technical Board - Decisions affecting R16 翻译）

OTP 技术委员会 - 影响R16的决策【翻译】

水平有限，错误之处请指正！

英文原文：OTP Technical Board - Decisions affecting R16

Written by Patrik, 16 Oct 2012

OTP技术委员会就产品和语言的未来发展做出决策。其中既考虑到爱立信内部使用者的需求，也考虑了开源方面的需求。

OTP技术委员会于2012年10月11日召开会议，讨论了哪些特性将会在即将发布的R16中被增加或删减。其中一些决定可能会影响开源社区，发布如下。

问题 1 - Unicode源代码

- 委员会决定寻找一个解决方案（像在Python里一样）将输入文件的编码格式告诉工具链。只有UTF-8和ISO-Latin-1编码会被支持。所有的源文件都可以在文件的开头添加相应注释，来标示包含UTF-8编码的字符（甚至从file:consult/1读入的文件）。

更改文件格式的工作将会逐步完成，以便工具能够接受Unicode的输入（意味着源代码可以包含Unicode字符串，甚至包括二进制结构），但是关于“atom”中字符的限制将会延续两个版本（应对分布式兼容问题）。R16中默认的文件编码是ISO-Latin-1，但会在R17中改为UTF-8.

源代码在R16版本时不需做任何改变，但是增加一个ISO-Latin-1编码的注释将确保代码在R17中也能被编译。在R16中增加一个UTF-8的注释将允许字符串和字符常量中包含代码点（code point）> 255的Unicode字符。同样的注释在R18中允许原子包含任意Unicode字符。因此在R18中函数名也可以包含任何Unicode字符。

UTF-8 BOM's使用不是很广泛，将不会被支持。

变量名将继续被限制在Latin字符集中。

问题 2 - 编译错误信息中的列号

- 委员会决定接受列号的补丁，尽管这会破坏abstract format的兼容性（关于abstract format：http://www.erlang.org/doc/apps/erts/absform.html）。会增加一个读取文件位置信息字段的提取器，以便在将来位置信息改变时不会引起不兼容。

这意味着包含行号的解析转换将需要被稍稍改写，以便能在R16里正常工作。

列号是不能配置的，总是在启用状态。

问题 3 - 如何处理不支持的特性 “包”

- “包”系统目前扰乱了OTP的代码。客观的说它从来没有被完全实现或支持。也极少有被用到。

如果我们想要一个系统去解决扁平的命名空间，那么这样的设计应该被重新评估，并做出改变，使它更适合于application的概念。

委员会决定，在R16中，去掉对“包”的支持。

问题 4 - 如何处理不支持的特性 “参数化模块”

- 委员会获悉很多软件都在使用这一特性，尽管它还处于实践阶段。当前使用的趋势是不能被接受的，而且参数化模块从来也没有作为一个特性被接纳到语言当中。这个特性不和module-fun's等兼容，也没有完整的被整合到OTP的其他工具中。

为了源代码的兼容性，委员会决定只去掉对参数化模块的语法支持。这意味着：

* 元组形式的模块调用依旧会被保留、支持，适当地文档化。

* 支持继承的错误处理功能将会被稍稍的增强，以便参数化模块能够包含存根，方便继承。错误处理的这个功能会有相应的文档。

* 分析程序会接受参数化模块的语法，但是如果参数化模块未被parse_transform(摘自erldoc：Parse transformations are used if a programmer wants to use Erlang syntax, but with different semantics. The original Erlang code is then transformed into other Erlang code. )处理，错误消息将随之产生（这些只涉及模块自身的实现）。

* 一个能处理使用了参数化模块源代码的解析转换器将会被公布出来，并且会被包含在任何需要它的包中。但它并不是OTP的一部分。As it uses supported and documented functionality, it will however be expected to work for forthcoming releases as well, or at least to be possible to adopt to forthcoming releases.

由于元组模块被保留，所以参数化模块的调用看起来会和今天一样。只是参数化模块自身需要使用解析转换来解决“不支持”的语法扩展。在虚拟机（以及shell）中通过参数化模块的实例来调用函数将像以前一样有效。

Best regards,

Patrik & Kenneth

---------------------

英文原文出自：OTP Technical Board - Decisions affecting R16 http://www.erlang.org/news/35