[erlang-questions] Breaking backwards compatibility in Release 17.0-rc2

Loïc Hoguin <>
Fri Feb 28 10:09:06 CET 2014

A macro for ?OTP_RELEASE or ?OTP_VERSION makes *absolutely no sense*. 
There are no guarantees that people are going to compile on a fresh 
Erlang release. If I create a release named PONIES, this will not help 
at all when I then use the compiler app I included to compile some stuff 
at runtime.

Something a little better is ?COMPILER_VERSION, but people might also 
run a custom compiler code with a custom version number, so that's a no 
go either.

On 02/28/2014 09:36 AM, Vlad Dumitrescu wrote:
> Hi,
> I've been hit by this too, as I have a patched debugger that I need to
> compile on older versions too and there are issues with
> unicode/maps/named funs. Unfortunately, there might be cases where code
> will still have to be duplicated, because macros can only wrap full forms.
>  From a brief look att epp.erl, it feels like adding a ?OTP_RELEASE or
> ?OTP_VERSION predefined macro would be easy and the only possible
> problem is if there are user-defined macros with the same name.
> predef_macros(File) ->
>       Machine = list_to_atom(erlang:system_info(machine)),
>       {ok, Release0} = file:read_file(code:root_dir()++"/OTP_VERSION"),
>       Release = string:strip(Release0, right, $\n),
>       ...
> {{atom,'OTP_RELEASE'},      {none,[{string,1,Release}]}},
>       ...
> By the way, wouldn't it be useful to have an erlang:system_info() that
> reads the file and strips the 'ok' and the whitespace?
> best regards,
> Vlad
> On Fri, Feb 28, 2014 at 1:08 AM, ANTHONY MOLINARO
> < <mailto:>> wrote:
>     I also have felt this pain with the transition from behaviour_info
>     to callbacks for behaviours.  Ideally, the preprocessor would define
>     a macro along the lines of ?MODULE, ?MODULE_STRING, ?FILE, ?LINE,
>     and ?MACHINE which is the full list according to
>     http://www.erlang.org/doc/reference_manual/macros.html.
>     If there was one additional macro call ?RELEASE with the major
>     release, then it would be possible to conditionally compile at least
>     dialyzer stuff (I don't know about the file encoding, I guess it
>     would depend on whether the check is done during the preprocessor or
>     at a later step).  This would probably prevent the proliferation of
>     different compile macros which seem to crop up as every individual
>     library adds their own based on a rebar or makefile check.
>     -Anthony
>     On Feb 27, 2014, at 3:06 PM, Jesper Louis Andersen
>     <
>     <mailto:>> wrote:
>>     Release 17.0 brings two changes which prove to take some work
>>     getting around.
>>     1. utf-8 is now the default encoding.
>>     This is a rather insignificant change. The source code which uses
>>     latin1 can be fixed by one of three ways:
>>     * Tell the compiler the file is latin1. This won't work going
>>     forward but works now.
>>     * Change the file to utf-8. This won't work going backward a long
>>     way. But it will work going backwards for a bit.
>>     * Change the file to ASCII. This works both backward and forward
>>     as long as we want.
>>     This is a benign problem. I have tried compiling some projects and
>>     it turns out there are numerous repositories which needs fixing
>>     now. But the fix is rather simple.
>>     2. Dialyzer dislikes queue(), dict(), ...
>>     Dialyzer now prefers using queue:queue() and the like. This is
>>     *definitely* the right thing to support as it is much more
>>     consistent with the rest of the system and doesn't treat certain
>>     types as magically introduced types.
>>     -module(z).
>>     -export([f/1]).
>>     -spec f(queue:queue()) -> queue:queue().
>>     f(Q) -> queue:in(3, Q).
>>     Which is nice, but this doesn't work on R16B03:
>>     z.erl:5: referring to built-in type queue as a remote type; please
>>     take out the module name
>>     z.erl:5: referring to built-in type queue as a remote type; please
>>     take out the module name
>>     So here, I have no way of getting my source code to work with both
>>     R16 and 17.0 easily. There is no transition period so-to-speak.
>>     Many projects run with warnings-as-errors and they are in trouble:
>>     * They can't compile
>>     * They can remove the warnings-as-errors but this defeats the purpose
>>     * They will have warnings spewed out over the console all the time
>>     In the case of crypto:hash/2, we had somewhat the same situation.
>>     Prominent projects like Yaws, and lesser projects like Emysql has
>>     EPP macros in place as well as detection in order to figure out
>>     what to do. Or you can disable the warnings in this case
>>     specifically for this. But can I do the same with wrong type
>>     specs? Also, this workaround is done in almost every project out
>>     there, which is darn irritating.
>>     I don't know what we need to solve this. At one point, I would
>>     really like to have a set of feature flags
>>     http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm
>>     , ZFS, ...
>>     where you have a way to compile-time scrutinize what your
>>     environment supports. Another way to solve it is the variant Go
>>     uses, namely "build constraints"
>>     http://golang.org/pkg/go/build/#pkg-overview
>>     which will mention under which circumstances to include a file as
>>     a part of an application. This would allow for easy handling of
>>     crypto:hash/2, but I do note it will fail on the dialyzer problem.
>>     It looks like the only sane way to solve that is to allow both
>>     queue() and queue:queue() as aliases for a major release and then
>>     proceed to remove queue().
>>     Am I completely wrong here? I can accept languages evolve and that
>>     Release 17 has maps which will be used and break a lot of software
>>     for R16 quickly. But I also feel we should have some way of having
>>     a process so there is a way to handle this gracefully going
>>     forward. It is natural for libraries and languages to evolve and
>>     break compatibility. Yet, it should be easy to handle for
>>     programmers. There is much time wasted, which could be used better
>>     were there a nice solution.
>>     Thoughts?
>>     --
>>     J.
>>     _______________________________________________
>>     erlang-questions mailing list
>>      <mailto:>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>     _______________________________________________
>     erlang-questions mailing list
>      <mailto:>
>     http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> http://erlang.org/mailman/listinfo/erlang-questions

Loïc Hoguin

More information about the erlang-questions mailing list