erlang - Saving a digraph to mnesia is hindered because of its side-effects -
updated
the digraph library in erlang implements data type side-effectful. each operation on data type saves new state in ets table -- instead of returning altered version of itself, more common in functional languages.
the problem usage perspective, impedes effort store or pass around state in convenient way requiring me first "collect" state before can start juggle around.
the closest solution have seen far serializer/deserializer, these have drawback tied current structure of digraphs instead of operating on abstract type -- prevents future proof solution.
update
pascal pointed out serializer utilizes interface of digraph, , hence eliminates drawback mentioned above. better, albeit still inconvenient, see no better alternative.
what recommendation on how store digraphs? should go different data type altogether?
thanks.
i not sure understand concern. fact digraph stored in ets transparent in user interface, might want chnge either exchange digraph process, make copy, or have permanent storage in case of crash.
for 2 first topics, quite easy retrieve definition of digraph in tuple {cyclic,protect,[vertice],[edge]}
, exchange it:
digraph_to_tuple(di) -> opt = digraph:info(di), vs = [digraph:vertex(di,x) || x <- digraph:vertices(di)], es = [digraph:edge(di,x) || x <- digraph:edges(di)], {proplists:get_value(cyclicity,opt),proplists:get_value(protection,opt),vs,es}. clone (di) -> {cyclic,protect,vs,es} = digraph_to_tuple(di), = digraph:new([cyclic,protect]), [digraph:add_vertex(do,v,n) || {v,n} <- vs ], [digraph:add_edge(do,e,s,d,n) || {e,s,d,n} <- es], do.
the last topic real problem since ets destroyed process created dies. there means giveaway ownership other process, in case independence ets implementation lost. better possibility create digraph in process , pass other process in charge manipulate them.
but not see mean have type of storage without re-writing part or whole module.
Comments
Post a Comment