<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-09-30 1:27 GMT+02:00 zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To iterate through the map you would have to loop over it. How does the map key generator track its place in the key list without maintaining a list, being like ETS, or being in a separate process? Assuming that what you mean isn't already maps:map/2 or maybe a maps:foreach/2?<br></blockquote><div><br></div><div>Easy, you keep track of it using an iterator context .. similar to a binary match context. Don't worry about it.</div><div><br></div><div>Keep in mind that all of those iterations in maps:map/2, maps:fold/3 and maps:foreach/2 are implemented using maps:to_list/1. This works but it's wasteful. Instead we reimplement those using an iterator. Less waste. 5 words less waste per pair if we implement it as an instruction otherwise 2 words. I would prefer the instruction approach. The compiler can always reassemble the return value to an 2-tuple if desired.</div><div><br></div><div>The iterator in gb_trees is not really fast either. It's faster to iterate over gb_trees:to_list/1 in most cases but it's there and it's useful if you want to save memory.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm trying to imagine what the calling code would look like where it isn't like maps:map/2, maps:fold/2 or a hypothetical maps:foreach/2, and maps don't become ETS... and drawing a blank.<br></blockquote><div><br></div><div>I think most cases can be handled by those functions. That's why they are there. </div><div><br></div><div>// Björn-Egil</div></div></div></div>