Implementing tables - advice wanted

[Taavi Talvik]

>> -----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).

This is nice enough.

> foo(X) ->
>     case dict:find(name, X) of
> 	{ok, Val} ->
> 	    bar(Val);
> 	error ->
> 	    ...
>     end.
>
> Contra:
>
> 	X = @{name=fred, age=12, footsize=8},foo(X)

If lookup time is small (like Richard wrote below) it would be
useful to do pattern matching with some special syntax.

For example:

foo(@{name=fred, age=12}=X) ->
	blaah;
foo(@{name=joe}=X) ->
	other_blaah.

IMHO special syntax for construction is not necessary.
Many languages have special constructs for hash table lookup.

PS. Year or two ago I played with same idea. Even implemented
(somewhat working) parsers and code transformation from pattern
matching to lookup+pattern matching.

best regards,
taavi

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