<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 2013-10-30 15:03, Chris King wrote:<br>
    </div>
    <blockquote cite="mid:op.w5rtcxqcvksmfo@shuttle.squirrel"
      type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <style type="text/css">body { font-family:'DejaVu Sans Mono'; font-size:12px}</style>
      On Wed, 30 Oct 2013 09:51:27 -0400, Björn-Egil Dahlberg
      <a class="moz-txt-link-rfc2396E" href="mailto:egil@erlang.org"><egil@erlang.org></a> wrote:<br>
      <br>
      <blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px
        solid; padding-left: 1ex">
        <div class="moz-cite-prefix"><br>
        </div>
        <blockquote cite="mid:op.w5rrm7itvksmfo@shuttle.squirrel"
          type="cite">
          <div><br>
          </div>
          <div>
            <div>I don't get this use case.  Why do you need syntax
              support for a key-value map where you don't know a priori
              what the keys and values are?  Why don't dict() and
              friends suffice?<br>
            </div>
            <div><br>
            </div>
            <div>To me this is akin to iterating through a record/tuple.</div>
          </div>
        </blockquote>
        <br>
        Actually these functions are needed, at least one is needed
        internally, I think.<br>
        <br>
        It should be covered in comprehensions with Maps generators.
        Maps generators needs next(Key, Map).<br>
        <br>
          But for small Maps and record like behaviour they are not
        needed. =)</blockquote>
      <div><br>
      </div>
      <div>Mm, I think I disagree about the need for map-generators as
        well.  Couldn't that be equally well served by implementing a
        qlc dict() source?</div>
    </blockquote>
    <br>
    What I meant was it needs a stepping structure internally. I don't
    think next(K,M) would suffice here though, need to think about it a
    bit more. All the comprehensions, generators, next, prev, tree
    structures and variables in keys goes hand in hand and those are a
    bit down the road. Don't fret about it =)<br>
    <br>
    <blockquote cite="mid:op.w5rtcxqcvksmfo@shuttle.squirrel"
      type="cite">
      <div><br>
      </div>
      <div>Well I shouldn't complain too much.  Richard O'Keefe and I
        both argued strenuously against conflating heterogeneous
        (record-like) and homogeneous (dict-like) maps months ago but I
        guess that ship has sailed.</div>
    </blockquote>
    <br>
    Yep.<br>
    <br>
    <blockquote cite="mid:op.w5rtcxqcvksmfo@shuttle.squirrel"
      type="cite">
      <div><br>
      </div>
      <div>I will just avoid using the dict-like features of these maps
        in my code, and hope that I am not forced to do so by the
        standard library or by popular applications.</div>
    </blockquote>
    <br>
    ofc.<br>
    <br>
    <blockquote cite="mid:op.w5rtcxqcvksmfo@shuttle.squirrel"
      type="cite">
      <div><br>
      </div>
      <div>BTW, is there a plan for a type notation for these new maps,
        or for how to get Dialyzer to usefully type-check them?</div>
    </blockquote>
    <br>
    Yes. The type notation is the same as with other terms. How well
    Dialyzer would be able to handle it is a different matter. I plan to
    make them really stupid at first, meaning opaque map(). Later
    incarnations of dialyzer could be increasingly smarter.<br>
    <br>
    // Björn-Egil<br>
  </body>
</html>