<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Re: 1. utf-8 is now default encoding<br>
    <br>
    The first bullet should only be: "Tell the compiler the file is
    latin-1." That is, this is supposed to work going forward.<br>
    <br>
    Andreas<br>
    <br>
    <div class="moz-cite-prefix">On 02/28/2014 01:05 PM, Andreas
      Schumacher wrote:<br>
    </div>
    <blockquote
cite="mid:58912684E2630B45963406CF7D8C52581C363BC5@ESESSMB103.ericsson.se"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
            <a class="moz-txt-link-abbreviated" href="mailto:erlang-questions-bounces@erlang.org">erlang-questions-bounces@erlang.org</a>
            [<a class="moz-txt-link-freetext" href="mailto:erlang-questions-bounces@erlang.org">mailto:erlang-questions-bounces@erlang.org</a>]
            <b>On Behalf Of </b>Jesper Louis Andersen<br>
            <b>Sent:</b> den 28 februari 2014 00:07<br>
            <b>To:</b> Erlang (E-mail)<br>
            <b>Subject:</b> [erlang-questions] Breaking backwards
            compatibility in Release 17.0-rc2<o:p></o:p></span></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <p class="MsoNormal">Release 17.0 brings two changes which
            prove to take some work getting around.<o:p></o:p></p>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">1. utf-8 is now the default encoding.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">This is a rather insignificant change.
              The source code which uses latin1 can be fixed by one of
              three ways:<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">* Tell the compiler the file is latin1.
              This won't work going forward but works now.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal">* Change the file to utf-8. This won't
              work going backward a long way. But it will work going
              backwards for a bit.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal">* Change the file to ASCII. This works
              both backward and forward as long as we want.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">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.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">2. Dialyzer dislikes queue(), dict(),
              ...<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">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.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <div>
              <p class="MsoNormal">-module(z).<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">-export([f/1]).<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">-spec f(queue:queue()) ->
                queue:queue().<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal">f(Q) -> queue:in(3, Q).<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Which is nice, but this doesn't work
                on R16B03:<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <div>
                <p class="MsoNormal">z.erl:5: referring to built-in type
                  queue as a remote type; please take out the module
                  name<o:p></o:p></p>
              </div>
              <div>
                <p class="MsoNormal">z.erl:5: referring to built-in type
                  queue as a remote type; please take out the module
                  name<o:p></o:p></p>
              </div>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">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:<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">* They can't compile<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal">* They can remove the
                warnings-as-errors but this defeats the purpose<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal">* They will have warnings spewed out
                over the console all the time<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">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.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">I don't know what we need to solve
                this. At one point, I would really like to have a set of
                feature flags <o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><a moz-do-not-send="true"
href="http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm">http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm</a>
                , ZFS, ...<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">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"<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><a moz-do-not-send="true"
                  href="http://golang.org/pkg/go/build/#pkg-overview">http://golang.org/pkg/go/build/#pkg-overview</a><o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">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().<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">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.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Thoughts?<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <p class="MsoNormal">-- <br>
              J. <o:p></o:p></p>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>