Suggestion: New table iterators
Thu Oct 19 10:49:14 CEST 2000
Perhaps ets:last/1 on a set table could be modified to actually fetch
the "last" object, and not the "first", as it does now?
(On set tables, ets:last/1 -> ets:first/1. I assume this was done
because order doesn't really make sense in a set table; even so, in
order for e.g. ets:foldr/3 to be implemented with ets:last/1 +
ets:prev/2, this would have to change.)
Apart from that, I think it's a good idea.
mnesia:fold[lr]/3 is a bit complicated, if e.g. we want to fold over
an ordered_set table inside a transaction, after objects have been
written to the table from within the same transaction. The new objects
have not been written to the original table yet, but reside in a
temporary table. Thus, the order is a bit more difficult to preserve.
On 19 Oct 2000, Bjorn Gustavsson wrote:
>I suggest that we add
> ets:foldl(Fun, Acc, Table)
> ets:foldr(Fun, Acc, Table)
> dets:foldl(Fun, Acc, Table)
> dets:foldr(Fun, Acc, Table)
> mnesia:foldl(Fun, Acc, Table)
> mnesia:foldr(Fun, Acc, Table)
>for iteration over tables.
>The difference between the foldl/3 and foldr/3 is the order in which the
>table elements are accessed. foldl/3 accesses from the first element to
>the last, while foldr/3 accesses the element from last to to first.
>Both functions are tail-recursive. The order is important only for ordered tables.
>There is no need for map/2 or filter/3 functions, because they can easily
>be simulated with the fold functions:
> my_tab2list(T) ->
> ets:foldr(fun (E, Acc) -> [E|Acc] end, , T).
>Besides, the reasonable semantics for map/2 and filter/3 would be that
>they modified the ets table or returned a new ets table, something we
>we are no prepared to implement now, but might be implemented in a future version.
Ulf Wiger tfn: +46 8 719 81 95
Strategic Product & System Management mob: +46 70 519 81 95
Ericsson Telecom AB, Datacom Networks and IP Services
Varuvägen 9, Älvsjö, S-126 25 Stockholm, Sweden
More information about the erlang-questions