Language change proposal

[Shawn Pearce]

Although a very slick idea, I think it would lead to much confusion
about why code was eliminated from the if statement.  Reading that
code one might reasonably expect to be able to compile it with version
5_3 and have it run the first group on 5_3, but the same module binary
would use different code on 5_2.  Too confusing.

If an application really MUST split into different code based on
different language versions, use different 'inner' modules.
Define functions in those modules which implement the given required
feature X on each language version, or have feature X throw/exit an error if
the platform cannot perform it.

Each 'inner' module can get compiled with the proper version(s) of
language, runtime, 3rd party libs, etc.  The more generic code
which doesn't care about versions can be compiled with the most
current, and get warnings/deprecation errors as necessary.

I liked the

	-module(mod, "5.3").

syntax, as it offers a nice way to determine the "format" of the file before
any other attributes might be set.  This might help an attribute linter, etc.
It would also be nice to be able to do:

	-module(mod).

and:

	erlc -assume_version 5.3 *.erl

to compile across an entire project without needing to set the version in
every header.  But really I think that putting the version number in all
new files, and having the compiler assume 5.2 for those that don't have a
version number is reasonable.  How hard is it really to put the version
number of the langauge / runtime you are targeting into the header of a module
when you write that module?  It certainly makes it clear what might be the
required version to make the silly thing work properly.

It might also be nice to define other dependencies such as:

	-require(stdlib, "5.3").

to indicate that this module would need a version of stdlib that understand
the calls available in version 5.3 of stdlib.  If version 6.8 of stdlib is
loaded, but it understands the 5.3 calls, then all is good.  If however
the currently loaded version of stdlib (6.8) does not understand 5.3 calls
then the code server should refuse to load this module.  (It might have
loaded it, checked M:module_info/1, then unloaded it when discovering
this problem.)

This would let a developer concisely code his expectations about the
versions of things he/she is using within their code, and make that
available to the OTP release handler, as well as linters, etc.


Joachim Durchholz <joachim.durchholz@REDACTED> wrote:
> However, there's one thing that /could/ be done: add an erlang_version 
> predicate that's guaranteed to be evaluated at compile time. Also, add 
> some rules about compile-time evaluation for expressions "known to be 
> constant" (these can be very simplicistic, look at the rules for Turbo 
> Pascal, for example).
> 
> With that, you can write stuff like (excuse the non-Erlang syntax here, 
> I've still not gotten around to making my ankles wet...)
> 
>    if erlang_version = "5_3"
>      % some code that uses bleeding-edge features here
>    else
>      if erlang_version = "5_2"
>        % some code that uses 5.2-isms here
>      else
>        some code that is dangerously language-version-unspecific here
>      endif
>    endif
> 
> Regards,
> Jo
> 

-- 
Shawn.