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

Fri Feb 28 10:01:16 CET 2014

I realized just now that the macros would only help me partially, as
compiling with the 17.0 compiler will produce a beam that won't run on
R15... I will have to find a different solution or to abandon the patched
version.

Anyway, a patch for the ?OTP_VERSION is available at
https://github.com/vladdu/otp/compare/erlang:master...version_macro. Of
course, maybe the name is not the right one and there's documentation to
add, if this is a change that is wanted.

regards,
Vlad

On Fri, Feb 28, 2014 at 9:36 AM, Vlad Dumitrescu <vladdu55@REDACTED> 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 <
> anthonym@REDACTED> 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 <
>> jesper.louis.andersen@REDACTED> 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
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140228/0cf9a2f2/attachment.htm>