[erlang-questions] Breaking backwards compatibility in Release 17.0-rc2
Vlad Dumitrescu
vladdu55@REDACTED
Fri Feb 28 10:45:34 CET 2014
On Fri, Feb 28, 2014 at 10:09 AM, Loïc Hoguin <essen@REDACTED> wrote:
> 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.
>
>
It would make sense for me, that's why I considered it. However, I agree
that my use case is special and is probably not enough to support this
addition by itself.
Since I have a patched debugger for erlide and I don't know which version
will users run their code on, I need to provide separate debuggers for all
supported versions and I am going to compile the code on fresh releases.
This isn't a problem until there are incompatibilities. I suppose that the
debugger is stable enough that I could maintain different patched variants
for the different versions, but it's still work that could be used for
other features/improvements/fixes.
regards,
Vlad
>
> 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
>> <anthonym@REDACTED <mailto: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
>> <mailto: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 <mailto:erlang-questions@REDACTED>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
> --
> Loïc Hoguin
> http://ninenines.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140228/b8ab7fe1/attachment.htm>
More information about the erlang-questions
mailing list