NEWS

Written by Patrik, 16 Oct 2012

 

The OTP Technical Board makes decisions regarding the future of the product and the language that are not possible to make directly by developers or development teams. It takes into consideration internalEricsson customer demands and needs as well as Open Source ditto.

OTP Technical Board had a meeting 2012-10-11 regarding features to add or remove from the product in the upcoming release R16. As some of the decisions may affect users in the open source community, the decisions are published here on the web.

Issue 1 - Unicode source code.

- The board decided to go for a solution where comments in the code (in the same way as in Python) informs the tool chain about input file encoding formats. This means that only UTF-8 and ISO-Latin-1  encoding will be supported. All source files can be marked as containing UTF-8 encoded Unicode characters by using the same mechanism (even files read using file:consult/1), namely formalized comments in the beginning of the file.

The change to the file format will be done incrementally, so that  the tools will accept Unicode input (meaning that source code can contain Unicode strings, even for binary construction), but restrictions regarding characters in atoms will remain for two releases (due to distribution compatibility). The default file encoding will be ISO-Latin-1 in R16, but will be changed to UTF-8 in R17.

Source code will need no change in R16, but adding a comment denoting ISO-Latin-1 encoding will ensure that the code can be compiled with the R17 compiler. Adding a comment denoting UTF-8 encoding will allow for Unicode characters with code points > 255 in string and character literals in R16. The same comment will allow for atoms containing any Unicode code point in R18. From this follows that function names also can contain any Unicode code point in R18.

UTF-8 BOM's will not be handled due to their limited use. 

Variable names will continue to be limited to Latin characters.

Issue 2 - Column numbers in compiler error messages.

- The Board decided to accept the patch for column numbers although it breaks compatibility regarding the abstract format. An abstraction for reading selected fields of the file position information will be added, so that changes to the position information will not cause incompatibilities in the future.

This means that "parse_transform's" concerning themselves with line numbers may need to be rewritten slightly to work in R16.

Column numbers will not be optional, they will always be enabled.

Issue 3 - What to do with unsupported feature 'packages'.

- The 'package' system as it is implemented today clutters the code of OTP. While being a fair idea from the beginning, it has not been fully implemented or in any way supported. It's also scarcely used.

If we would want a system to remove the flat name space, the design should be reviewed and probably changed to better fit the current application concept.

The board decided to remove the unsupported 'packages' support from the product in R16.

Issue 4 - What to do with unsupported feature 'parameterized modules'.

- The board acknowledges that a lot of software relies on this feature although it's always been experimental. The current form of the implementation is not acceptable and the parameterized modules as such has never been accepted as a feature in the language. The feature is also not compatible with for example module-fun's and is not fully integrated with the rest of the tools in OTP.

To allow for source code compatibility, the board decides to only remove the syntactic support for parameterized modules. This means:

* Apply with tuple modules will be retained, supported and properly documented.

* Error handler functionality that today supports inheritance will be slightly generalized, so that parameterized modules can contain stubs to facilitate inheritance. The functionality in the error handler will be documented.

* The parser will accept the syntax for implementation of parameterized modules, but if the parameterized modules are not handled by a parse_transform, an error message will be generated at a later stage (this concerns the implementation of the modules themselves only).

* A parse_transform handling source code implementing a parameterized module will be published in the public domain, free to use and include in any package needing it. It will however not be part of 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.

As apply with tuple modules is retained, calls to parameterized modules will remain as they look today. Only the implementation of the parameterized modules themselves need to apply a parse transform to allow for the "unsupported" syntax extensions. Calling a function in an instance of a parameterized module from an evaluator (e.g. the shell) will also work as before.

Best regards,

Patrik & Kenneth 

Tags: []

Filter news by:

Powered by Erlang Web