Proposed change to libraries

[Kostis Sagonas]

Bjorn Gustavsson wrote:
 > > It is essentially the same, just packaged in a much more elegant way.

Ok, at least now I know we are on the same wavelength.

 > > The key question is: does "is_applicable({M,F}, 1)" always check that
 > > the M:F/1 is a valid fun (and succeeds accordingly) or not?
 > > 
 > 
 > No. is_applicable/2 cannot still check whether M:F/A will be possible to
 > apply or not. is_applicable/2 would have to assume that any tuple containing
 > two atom elements is a valid tuple fun.
 > 
 > But as I see two advantages using is_applicable/2:
 > 
 > 1) When/if we'll finally be able to eliminate tuple funs, we can change 
 >    is_applicable/2 to no longer accept tuple funs (as opposed to changing
 >    Erlang code in many places).
 > 
 > 2) When Dialyzer sees is_applicable/2, it is a stronger type indication
 >    than just 'foo({M,F}) when is_atom(M), is_atom(F)' which need not be
 >    a tuple fun. At least it should be enough indication for Dialyzer to
 >    assume that F has the same type in both clauses of lists:map/2. That
 >    should allow Dialyzer to generate more warnings than it can today.
 > 
 > If it would be of help to Dialyzer, we might be able to add is_applicable/2
 > even to R10B-4 (and start using it in library modules such as lists).

Sounds a reasonable plan.  Since is_applicable/2 will, some fine day,
be changed to only accept proper funs in its first argument and till
then will only be doing crippled tests with tuple funs anyway,
let me propose that we call this is_function/2 instead.

So map/2 will read:

  map(F, [F|T]) -> [F(H)|map(F,T)];
  map(F, []) when is_function(F,1) -> [].

This is more consistent with the current is_function/1 guard (which 
is the is_applicable/1 which Richard O'Keefe has described).
(Moreover, you can see the current implementation of is_function/1
 as one where the tuple fun case is already gone! :-)

Kostis