Implementing tables - advice wanted

[Joe Armstrong (AL/EAB)]

> -----Original Message-----
> From: ke han [mailto:ke.han@REDACTED] 
> Sent: den 13 juni 2006 14:25
> To: Richard Carlsson
> Cc: Joe Armstrong (AL/EAB); erlang-questions@REDACTED; 
> Björn Gustavsson
> Subject: Re: Implementing tables - advice wanted
> 
> 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.

No

> 2 - If the the idea is simply to have a syntax for 
> constructing immutable tables, this could be nice. 

Yes

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

In Lua keys strings and integers.

One design decision might be to limit the keys to say atoms, strings and integers
In Lua tables contain two areas - a hash table and an array table. If Lua 
can find some integer key N such that half the slots from 1 .. N are in use and at least
one slot from N/2 to N are in use then it will put these items into an array
Exceptions are put into a regular hash table.


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

No - this is more a syntax thing


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

Absolutly. keys(X) should return a list of all the keys in X
(for meta programming)

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