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

Tue May 10 02:26:49 CEST 2016

On 10/05/16 1:22 AM, Lukas Larsson wrote:
> On Mon, May 9, 2016 at 2:54 PM, zxq9 <zxq9@REDACTED 
> <mailto:zxq9@REDACTED>> wrote:der?
>
> For one thing Mr. Virding needs them to implement his lua erlang 
> language thing :)A
If we're going to let Lua dictate Erlang semantics, we might we well
go all the way and be fully Perl compatible as well.  In fact he
doesn't *need* them for Lua.  They would be very *convenient*,
and they would improve *efficiency* of the imitation, but at the
price of a little indirection, they aren't *necessary*.

> We also could make great use of them in the standard libraries to 
> build efficient variants of maps:fold and friends.

Like I said, my Smalltalk system has 760 public methods in the interface
of Dictionary, and first/next are not only not amongst the public methods,
they are not amongst the private methods either.  Basically, all of the
"bulk" methods (maps:fold and friends) are or could be layered on top of

     aDictionary keysAndValuesDo: [:key :value |
        ... do something with a key and a value ...].

If I did have analogues of first/next, they would be O(n) worst case time
and even on the average would be markedly slower than using the method
above.

Of course that requires being able to update a mutable state, so the
analogue for Erlang would be maps:fold itself.
>
> I'm sure there are usecases that we have not seen yet that will come 
> up. I've learned over the years that people never use the API:s you 
> create the way to expect them to be used and always come up with the 
> strangest and cleverest ways of doing things.

To use a phrase of my father's, "You slobbered a bibful there, bub."
(Meaning heartfelt agreement.)  Of course one way to deal with this is to
provide lots of examples, so that the *easiest* way for people to use
your procedures is to follow the pattern you've given them.

The basic problem at the moment is that almost any use case for
operations with undefined results has to be a use case that yields
undefined results itself, and I am not sure why it is important to
support use cases with undefined results.

Suppose there were a first/next interface for maps relying on an
adaptive data structure to provide O(lg n) per element time for
a first traversal and O(1) per element time for subsequent traversal.
Which is doable.  Could this break any Lua program?  No, an
unspecified order is an unspecified order, and this particular order
will do as well as any other.  Could the time matter?  No, there
is nothing in the Lua reference manual making any guarantees
whatsoever about next(table[, index]).  (I just checked the Lua 5.3
manual to make sure.)  Next could be O(n) time per call, and a
Lua programmer might be surprised, but no promises would have
been broken.   next(table[,index]) isn't even the recommended way
to iterate over a table, that's
    for k, v in pairs(t) do <body> end