Proposed change to libraries

Kostis Sagonas kostis@REDACTED
Wed Feb 9 12:09:49 CET 2005


Let me throw another proposal to this thread.

First let me enumerate the things we (all?) agree upon:

 1. Something needs to be done in libraries to make them more consistent
    with their documentation and allow more effective type checking.
 2. Tuples-as-funs need to be handled somehow but only for a
    transitional period (of currently unspecified length ;-).
 3. The checks that will be performed for tuples-as-funs cannot be as
    strong as (at least some of us) would like them to be.
 4. Some new built-in guards have to be introduced.  If they handle
    tuples-as-funs, this handling will be taken out when their support
    is discontinued.
 5. It is probably not a good idea to modify the semantics of existing
    guards (e.g. is_function/1) to also handle tuples-as-funs only to
    take these modifications away some fine day.

So, here is an alternative proposal that satisfies the above constraints
and allows us to do more effective type checking.  Modify map/2 to look
as follows:

    map({M,F}, L) -> map(fun(X) -> M:F(X) end, L);
    map(F, [H|T]) -> [F(H) | map(F, T)];
    map(F, []) when is_function(F,1) -> [].

and then is_function/2 only handles proper fun objects.  Besides being
much cleaner, I think, it also has the extra advantage that calls to
map/2 with a tuple-as-fun also work when compiled in native code (which
currently they do not).  Then taking out support for tuples-as-funs is
just a matter of removing the extra clause -- the semantics of all guards,
current or new, remains unchanged.

Kostis.




More information about the erlang-questions mailing list