<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 2016-04-11 13:25, José Valim wrote:<br>
    </div>
    <blockquote
cite="mid:CAGnRm4Lmr6NTXaHZK5rVAoWN6y=8Tc-65F9_D18iE78deGBrFg@mail.gmail.com"
      type="cite">
      <div dir="ltr">That's excellent news Kostis!
        <div><br>
        </div>
        <div>I have only one question/reservation:</div>
        <div><br>
        </div>
        <blockquote style="margin:0px 0px 0px
          40px;border:none;padding:0px">
          <div>Another problem is related to the meaning of #{}. One
            would expect that this notation means "the empty map," but
            instead it means "any map".</div>
        </blockquote>
        <br>
        <div>#{} in pattern matching also means "any map", so it may be
          confusing to have #{} in specs to mean the empty map,
          specially because both usages are often close to each other.
          For example:</div>
        <div><br>
        </div>
        <div>
          <blockquote style="margin:0px 0px 0px
            40px;border:none;padding:0px">
            <div>-spec increment(term(), #{}) -> #{}</div>
          </blockquote>
          <blockquote style="margin:0px 0px 0px
            40px;border:none;padding:0px">
            <div>increment(Key, #{} = Map) -></div>
          </blockquote>
          <blockquote style="margin:0px 0px 0px
            40px;border:none;padding:0px">
            <div>  Map#{Key := maps:get(Key, Map) + 1}.</div>
            <div><br>
            </div>
          </blockquote>
        </div>
        <div>I also understand that [] and {} in typespecs implies
          emptiness and making #{} mean "the empty map" would make the
          typespecs more consistent.<br>
        </div>
      </div>
    </blockquote>
    Actually, that is not the reason I wanted to make this change.
    Rather, it is inconsistent with the <tt>#{PairList}</tt> syntax.
    Consider the type <tt>#{x=>_, y=>_}</tt>. This type may only
    contain the keys <tt>x</tt> and <tt>y</tt>. So, the value <tt>#{x=>1,
      y=>2, z=>3}</tt> does not belong to this type.<br>
    Now consider what happens when we change the type to <tt>#{x=>_}</tt>;
    the type is made more restrictive. The key <tt>y</tt> is no longer
    allowed. But if we repeat this process and change it to <tt>#{}</tt>,
    suddenly we have not made the type more restrictive; we made it more
    allowing!<br>
    <br>
    In fact, I have seen several people (myself included!) be fooled by
    the <tt>#{}</tt> base case into believing that the <tt>#{x=>_,
      y=>_}</tt>, means the set of values that match the pattern <tt>#{x=>_,
      y=>_}</tt>, which is not the case (written with the new syntax,
    that type would be <tt>#{x:=_, y:=_, ...}</tt>).<br>
    <br>
    So, I saw an opportunity to make the syntax self-consistent and more
    intuitive before it would become harder to change. Either by
    changing the semantics of everything but <tt>#{}</tt> in order to
    be consistent with pattern matches, or by just changing <tt>#{}</tt>
    to be consistent with the rest.<br>
    <br>
    Considering that the former would have broken the ability to write
    associative-array-maps as <tt>#{Key => Value}</tt> (or required
    even more special cases), the choice was clear.<br>
    <br>
    <blockquote
cite="mid:CAGnRm4Lmr6NTXaHZK5rVAoWN6y=8Tc-65F9_D18iE78deGBrFg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>That said, maybe it would be better to not allow #{}
          altogether (deprecating it now and removing it later) and
          introduce an empty_map() construct? The empty_map() type is
          slightly more verbose but I don't expect it to be used
          frequently and, as such, the more explicit name is worth it.
          And if I understand the proposal correctly, both map() and #{_
          => _} can still be used to represent any map, while #{_ :=
          _} represents a non-empty map, so it feels all of our bases
          are covered.</div>
        <div><br>
        </div>
        <div>Thank you,</div>
      </div>
      <div class="gmail_extra"><br clear="all">
      </div>
    </blockquote>
    Although I am not against introducing an <tt>empty_map()</tt>
    alias, I don't think disallowing <tt>#{}</tt> would solve the
    problem. Indeed, your example can be trivially altered to commit the
    same mistake without using the <tt>#{}</tt> type;<br>
    <div><br>
    </div>
    <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
      <div><tt>-spec increment(term(), #{count := C}) -> #{count :=
          C}.</tt></div>
    </blockquote>
    <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
      <div><tt>increment(Key, #{count := C} = Map) when C >= 0 -></tt><tt><br>
        </tt><tt>  Map#{Key := maps:get(Key, Map) + 1}.</tt><br>
      </div>
    </blockquote>
    <br>
    If anything, I think the <tt>#{}</tt> case is the clearest example
    of type =/= pattern, and removing it would just obscure the problem.<br>
    <br>
    Thanks for your feedback<br>
    // Magnus Lång<br>
    <br>
    <blockquote
cite="mid:CAGnRm4Lmr6NTXaHZK5rVAoWN6y=8Tc-65F9_D18iE78deGBrFg@mail.gmail.com"
      type="cite">
      <div class="gmail_extra">
        <div>
          <div class="gmail_signature">
            <div dir="ltr">
              <div>
                <div><span style="font-size:13px">
                    <div><span
style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José
                          Valim</b></span></div>
                    <div><span
style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse">
                        <div><span
                            style="font-family:verdana,sans-serif;font-size:x-small"><a
                              moz-do-not-send="true"
                              href="http://www.plataformatec.com.br/"
                              style="color:rgb(42,93,176)"
                              target="_blank"><a class="moz-txt-link-abbreviated" href="http://www.plataformatec.com.br">www.plataformatec.com.br</a></a></span></div>
                        <div><span
                            style="font-family:verdana,sans-serif;font-size:x-small">Skype:
                            jv.ptec</span></div>
                        <div><span
                            style="font-family:verdana,sans-serif;font-size:x-small">Founder
                            and Director of R&D</span></div>
                      </span></div>
                  </span></div>
              </div>
            </div>
          </div>
        </div>
        <br>
        <div class="gmail_quote">On Mon, Apr 11, 2016 at 12:45 PM,
          Kostis Sagonas <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:kostis@cs.ntua.gr" target="_blank">kostis@cs.ntua.gr</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">On
            03/04/2016 11:59 AM, Björn-Egil Dahlberg XB wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <br>
              I did the initial work for maps in Dialyzer but that
              application is not<br>
              really part of my work area. If you want to contribute to
              Dialyzer you<br>
              should probably talk to Hans Bolinder, Kostis Sagonas
              and/or Stavros<br>
              Aronis. Hans talked about increasing Dialyzers knowledge
              about map<br>
              associations the other day but I don't think it is on his
              agenda at the<br>
              moment.<br>
              <br>
              I don't think it will be supported in 19.0 either though I
              have no clue<br>
              if Kostis or Stavros, or anyone else for that matter, is
              working on it.<br>
            </blockquote>
            <br>
            <br>
            Hijacking this thread to announce a proposal for a change in
            the type syntax related to maps.<br>
            <br>
            The relevant document is here:<br>
            <br>
              <a moz-do-not-send="true"
              href="https://gist.github.com/kostis/eaf4a06e643cf49314ba"
              rel="noreferrer" target="_blank">https://gist.github.com/kostis/eaf4a06e643cf49314ba</a><br>
            <br>
            We would appreciate feedback from the community at this
            point.<br>
            <br>
            The intention is for this change to be part of Erlang/OTP
            19.0.<br>
            <br>
            <br>
            Kostis<br>
            <br>
            PS. Most of the credit for this change goes to Magnus Lång.<br>
            <br>
            PS2. For those that would like to experiment with the new
            type syntax and use the new version of dialyzer, or just
            fancy reading code diffs, there is also a related pull
            request that implements all these:<br>
            <br>
              <a moz-do-not-send="true"
              href="https://github.com/erlang/otp/pull/1014"
              rel="noreferrer" target="_blank">https://github.com/erlang/otp/pull/1014</a><br>
            <br>
            <br>
            _______________________________________________<br>
            erlang-questions mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
            <a moz-do-not-send="true"
              href="http://erlang.org/mailman/listinfo/erlang-questions"
              rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>