Implementing tables - advice wanted

[ke han]

I have programmed in Smalltalk for about 15 years and find the  
collection types key to every app.  Dictionary is very important.   
However, these are all mutable objects.
1 - If the idea to have a table syntax is to introduce mutable  
collections, I would say it would quickly lead to a breakdown of the  
single assignment nature of erlang programs.
2 - If the the idea is simply to have a syntax for constructing  
immutable tables, this could be nice.  But any "real" app will have  
large enough or unpredictable "structure" in these tables meaning  
that almost all programs will access the table "object" via an API,  
not a syntax where the names of fields are hard coded.  Your syntax  
does look nice and could prove useful for teaching erlang, but the  
core API would be used more for larger apps.
3 - I don't see much value in this new data type if the key must be  
only atoms or strings.  Too restrictive and would only server special  
cases.  I am used to using hash table where the key may be a domain  
object.  Unless of course, you can create a non-mutable, highly  
performant, space conscious hash table to replace most uses of record.
4 - Is the performance/space characteristics of module dictionary  
lacking?

It is common practice (smalltalk, java, python, ruby) in model and  
controller frameworks to store attributes as hash tables keyed by  
attribute name.  This representation is very handy for abstract  
framework code to manipulate attributes, handle events, etc...   
However, the code should always encapsulate the internal  
implementation.  This means the app programmer never sees the  
dictionary/hash table.  So syntactic sugar for creating/accessing the  
tables isn't exposed to the app programmer.  Smalltalk and Java have  
several good dictionary types but do not have special syntax for  
them.  This works out just fine.

What I really need is the ability to pass around records (treat them  
as objects: meaning I have the discipline not to access them directly  
but via some module which owns its representation)  and reference the  
fields by name via some record module's API.   So, why would I need  
to have a record's fields be available outside its created module if  
I'm disciplined enough to always use said module to access the  
record?  Well, for creating abstract frameworks and helper "objects",  
of course.  I need to write some reusable "abstract" modules that are  
closely coupled to their "concrete" counterpart.  This abstract code  
needs to know things about the record.  I am doing just that in some  
erlang framework code I'm working on, but I feel its a bit clumsy and  
may not be efficient.   I would think just one or two well performing  
APIs for record field would be just what I need.

I also need a good template engine for yaws ;-)

just my 2 cents, ke han



On Jun 13, 2006, at 6:30 PM, Richard Carlsson wrote:

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