2008/11/20 Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On 20 Nov 2008, at 11:45 am, damien morton wrote:<br>
> Hmm, I see - these fixed-up records would be dictionary-like data<br>
> structures, with a supporting syntax for dictionary literals and<br>
> pattern matching. They would lose the very fast lookup access that<br>
> records have, though they would gain the expandability that a<br>
> dictionary-type (proplist,hashtable,tree) data structure offers.<br>
...<br>
</div>My proposal comes with an implementation sketch<br>
that *does* store the keys and the values separately.<br>
Up to tagging, a frame is basically<br>
        {{foo,bar,ugh,zoo},X,Y,Z}<br>
and the "descriptor" part would normally be shared.<br>
This in no way impairs extensibility; the descriptor<br>
doesn't *have* to be shared.</blockquote><div><br>Richard, one question about implementations. In some discussions I have had with people about such an extension (all want it) is that many see it not only as a replacement for records but also as a replacement for dict/gb_trees/sometimes even ets. Do you think it is possible to have one data structure which would efficiently span such a large range of entries? From 0 in frames to 100,000s in in dict/gb_trees?<br>
<br>I personally don't think it is possible, without changing internal representation somewhere. But if we have two different packages, frames and dicts, then we get the problem of trying to explain to people the difference between them and when to use which.<br>
<br>I am all for adding something like frames, but I also think it is best to leave records in the system as they are. While we are at it I would like to see a hash table data type which could be used as a basis for dict to make it more efficient.<br>
<br>Robert<br><br></div></div>