[erlang-questions] "Remote" types in Erlang (Re: Breaking backwards compatibility in Release 17.0-rc2)

[Kenji Rikitake]

While I agree with the need of feature flags or the run time environment
version identifier macros, I think the following Dialyzer type issue needs
transitional solution between R16 and 17 and a separate attention from the OTP
team. I've been just facing this issue while I'm writing pieces of code for
coming Erlang Factory.

I should also say that orddict() was not among the "magically introduced
types" in R16B03-1; I had to steal the definition from
lib/stdlib/src/orddict.erl in R16B03-1. 

Kenji Rikitake

++> Jesper Louis Andersen <jesper.louis.andersen@REDACTED> [2014-02-28 00:06:34 +0100]:
> Release 17.0 brings two changes which prove to take some work getting
> around.
[snip]
> 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.