Implementing tables - advice wanted

[Joe Armstrong (AL/EAB)]

Second try, my last mail got sent prematurely ...
 

> -----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 about the syntax.

     Try this:

	X = @{name="fred", age=12, footsize=8}
	foo(X)


      foo(@{name=Name}=X) ->
	    ...
      foo(Other) ->

This matches a table with key "name"

How does this look with dicts?

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

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

Which is much more verbose.

I recently attended a dagstuhl workshop where one of the
topics was "tables as universal data structures" - some of the people
there thought that "the python data structures were just hash tables and
this was why python was popular".

>
> 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?

Strange - I can't understand what "interaction with GC" has to do with
matters. 

/Joe 





> 	/Richard
> 
>