1
%% This testcase shows why it's a bad idea to block refinement (by forwarding
2
%% any() to all arguments) when a failing call is encountered. The initial
3
%% success typing for update_one allows anything to be an element of the list in
4
%% the second argument. This will be refined during dataflow by the result from
5
%% add_counters to just a list of tuples. This will cause the call in the second
6
%% clause of update_one to fail correctly and identify the discrepancy. It could
7
%% be a better idea to refuse to add the failing calls but this may lead to a
8
%% ton of unused functions,
10
%% by Stavros Aronis<aronisstav@gmail.com>
12
-module(refine_failing).
16
foo(A, B) -> update_all(add_counters(A, []), B).
18
add_counters( [], Acc) -> Acc;
19
add_counters([H|T], Acc) -> add_counters(T, [{H, 0}|Acc]).
21
update_all(Ds, []) -> Ds;
22
update_all(Ds, [F|Fs]) -> update_all(update_one(F, Ds, []), Fs).
24
update_one(_F, [], Acc) -> Acc;
25
update_one( F, [{F, Cr},Ds], Acc) -> update_one(F, Ds, [{F,Cr+1}|Acc]);
26
update_one( F, [ D|Ds], Acc) -> update_one(F, Ds, [ D|Acc]).