[erlang-questions] Wanted additions to the maps module?

[zxq9]

On Tuesday 10 May 2016 00:02:38 ok@REDACTED wrote:
> > On Mon, May 9, 2016 at 2:01 AM, Richard A. O'Keefe <ok@REDACTED>
> > wrote:
> >
> >> I thought maps were *not* intrinsically ordered.
> >>
> >
> > They aren't.
> >
> > You don't need a defined order in order to iterate using first and next,
> > see for example how ets:first/ets:next work on a set.
> 
> You *do* need a defined order for iteration to *make sense*.
> If the value of maps:first_key(Map) and maps:next_key(Map, Key)
> is not *determined* by the *value* of Map (without reference to
> the history of how the Map was built or any other inscrutable
> properties such as where it happens to be stored), then these
> things just aren't functions.
> 
> Since we *do* have an ordering on terms, it *would* be possible
> to define 'first' as 'least in standard order' and 'next' as
> 'next smallest in standard order'.
> 
> Without some clearly defined history-independent order being
> set up for these functions, you can end up with two *equal*
> maps being traversed in different orders.

I thought I was the only one who thought this was odd, but I was shouted
down once a while back mentioning it because "I just didn't understand".

"next" implies a "previous" and that implies an ordering -- and that
ordering seems like it should mean something (or, in other words, be
consistent). Or... what am I missing?

I'm all for having a maps:next/1 & maps:previous/1, but that really seems
to imply an ordering, and it also seems to imply some super explicit
explanation of the behavior between calls in different scopes and between
changes to the contents of the map (but since each change to the map
supposedly returns a *new* map, and each time a map is read in a new
scope it should also be considered to be a new map... ?).

Dunno... seems more like a desire to have a maps:map/2, maps:foldl/2,
maps:kfoldl/2, maps:vfoldl/2, maps:kforeach/2, maps:vforeach/2, etc.
should be handled by an explicit function -- instead of succumbling to
(what to me) feels like a temptation to make maps have a Python-like
iterator.

Can someone explain the use case for next/1 and what is different about
it than having a selection of more specific and explicit functions that
cover the cases where we want to iterate over the map (to include
shortcutting/backtracking/reporting, as in a "pipe" type list function)?

-Craig