[erlang-questions] Maps

[Loïc Hoguin]

On 05/13/2013 07:26 AM, Richard A. O'Keefe wrote:
>
> On 11/05/2013, at 2:34 AM, Loïc Hoguin wrote:
>> Not dismissing it here, I'd be happy to have both, but maps are solving a problem (dict manipulation is incredibly tedious and time consuming in Erlang) while frames simply improve what we already have.
>
> There is another EEP that I haven't finished trying to set up a *general*
> solution for the "deep updates" problem.  It really isn't a data structure
> issue.

Don't forget the "deep access" possible not only in expressions but also 
in function clauses. You'd only be solving half the problem otherwise.

>   - a syntax for that data structure which makes it seem as though it is strongly
>     recommended as a record replacement (and that is *precisely* how Joe Armstrong
>     has taken it; the new book he's working on uses maps where it would otherwise
>     have used records or frames)

To be perfectly honest I don't think that for most record uses this is 
going to be much of a problem. There's plenty of #state{} records in 
user applications that aren't accessed enough to make this significant.

And if you wait 10 years, any performance difference will be 
insignificant...

> These things can be decoupled.  We can have a "deep updates" solution
> that works for lists AND tuples AND records AND frames AND maps.  We
> can have a top notch data structure.  And these things do not require
> maps to use frame-like syntax.

I would agree for key/value structures, but I fear that by including 
lists and non key/value tuples you're going to make this much too complex.

Another very important thing that maps have and your solution wouldn't 
have, is that the syntax carries semantics that your solution won't 
have. For example you can't add new fields to a record, while you can to 
maps. If the same syntax is used for everything then that means I need 
to look elsewhere to understand the code. The maps EEP doesn't force me 
to do that.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu