Erlang futures

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Erlang futures

James Hague-3
I wrote:

> 1. If you are doing things like fetching and parsing web
> pages, just handle the pages as binaries. It is just as easy
> to parse a binary as a string, and there is no wasted space.

On that subject, here is a binary version of lists:splitwith, which I have
found handy:

% Split a binary into two parts and return {list, binary}.

splitwith(Pred, B) ->
   splitwith(Pred, B, []).
splitwith(Pred, <<Hd,Tail/binary>>=B, Taken) ->
   case Pred(Hd) of
      true  -> splitwith(Pred, Tail, [Hd|Taken]);
      false -> {lists:reverse(Taken), B}
   end;
splitwith(Pred, <<>>, Taken) ->
   {lists:reverse(Taken),[]}.


James


Reply | Threaded
Open this post in threaded view
|

Erlang futures

Robert Virding-4
James Hague <jamesh> writes:

>On that subject, here is a binary version of lists:splitwith, which I have
>found handy:
>
>% Split a binary into two parts and return {list, binary}.
>
>splitwith(Pred, B) ->
>   splitwith(Pred, B, []).
>splitwith(Pred, <<Hd,Tail/binary>>=B, Taken) ->
>   case Pred(Hd) of
>      true  -> splitwith(Pred, Tail, [Hd|Taken]);
>      false -> {lists:reverse(Taken), B}
>   end;
>splitwith(Pred, <<>>, Taken) ->
>   {lists:reverse(Taken),[]}.

To be truly a binary version it should return two binaries not a list
and binary.  I think the easiest and most efficient way would be:

splitwith(Pred, B) ->
    split_binary(B, splitwith(Pred, B, 0)).

splitwith(Pred, <<H:8,T/binary>>, I) ->
    case Pred(H) of
        true -> splitwith(Pred, T, I+1);
        false -> I
    end;
splitwith(Pred, <<>>, I) -> I.

For example this is also what is wrong with ets:filter/3, it returns a
list but it should really return a filtered ets table.

        Robert
--
Robert Virding                          Tel: +46 (0)8 545 55 017
Alteon Web Systems                      Email: rv
S:t Eriksgatan 44                       WWW: http://www.bluetail.com/~rv
SE-112 34 Stockholm, SWEDEN
"Folk s?ger att jag inte bryr mig om n?gonting, men det skiter jag i".


Reply | Threaded
Open this post in threaded view
|

Erlang futures

Ulf Wiger-4
On Wed, 18 Apr 2001, Robert Virding wrote:

>For example this is also what is wrong with ets:filter/3, it returns a
>list but it should really return a filtered ets table.

Hmm, except that ets tables are not garbage collected, and there's
an upper limit on the number of ets tables that can be created.
Such a function would not be side effect free, in the sense that
the caller would then explicitly have to deallocate the automatically
created ets table... unless:

ets:filter(Tab, F, A, ResultTable) -> true.

where the result of the filter operation is found in ResultTable

But the basic idea of ets:filter/3, ets:foldl/3 et al was that they
would be analogous to the corresponding lists functions. The
most important reason for putting them in was that it would be
easy to modify code that first called ets:tab2list(Tab) and
then iterated over the result -- this being bad because it causes
trouble for the Erlang memory handling.

/Uffe
--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB



Reply | Threaded
Open this post in threaded view
|

Erlang futures

Robert Virding-4
Ulf Wiger <etxuwig> writes:
>But the basic idea of ets:filter/3, ets:foldl/3 et al was that they
>would be analogous to the corresponding lists functions. The
>most important reason for putting them in was that it would be
>easy to modify code that first called ets:tab2list(Tab) and
>then iterated over the result -- this being bad because it causes
>trouble for the Erlang memory handling.

Yes, but a map/fold/filter is really a function <type> -> <type> not a
function <type> -> <list>.  So in lists it goes [X] -> [X] and in ets
it should go ets(X) -> ets(X) NOT ets(X) -> [X].

I quite understand why they are there, they should be there.  My
comment was just that they should "return" an ets table not a list.
Considering ets itself is destructive it would be ok for
ets:map/fold/filter to also be destructive and modify the original
table.  To late to change, but it is a pity.

        Robert