Implementing tables - advice wanted

[Joe Armstrong (AL/EAB)]

> -----Original Message-----
> From: Richard Carlsson [mailto:richardc@REDACTED] 
> Sent: den 13 juni 2006 12:30
> To: Joe Armstrong (AL/EAB)
> Cc: erlang-questions@REDACTED; Björn Gustavsson
> Subject: Re: Implementing tables - advice wanted
> 
> Joe Armstrong (AL/EAB) wrote:
> > Erlang really really really (^100) needs tables.
> 
> Allow me to disagree somewhat. Erlang already has good 
> tables, both using hashing (dict) and binary trees 
> (gb_trees). The syntactic convenience of a built-in 
> table/dictionary type is really a minor thing. (Not that I 
> would oppose having such a notation, but I really don't think 
> it is critical in any way.) The main advantage would be 
> psychological, I think: a standard one-size-fits-all 
> dictionary type makes it easier for people to start using 
> them in public interfaces, and not just internally.

I disagree

    X = dict:from_list([{name,fred},{age,12},{footsize,8}]),
    foo(X).

foo(X) ->
    case dict:find(name, X) of
	{ok, Val} ->
	    bar(Val);
	error ->
	    ...
    end.

Contra:

	X = @{name=fred, age=12, footsize=8},foo(X)
      
   
	
    X1 = dict:store( 



> What I _do_ miss now and then (and when I need them, I have 
> to jump through several hoops to get them) is indexable 
> tables (i.e., arrays) with O(1) access time and a _small_ 
> constant factor, and no copying of the stored data.
> 
> If I remember correctly, the experiment with a "vector" data 
> type (which used destructive update internally, with some 
> penalty for accessing older versions of the data) was killed 
> by bad interaction with the garbage collector, leading to 
> rotten performance. Have things changed enough in the GC by 
> now for this to become worth a new attempt?
> 
> 	/Richard
> 
>