Re: [Caml-list] What is an applicative functor?

[Andreas Rossberg <rossberg@mpi-sws.org>]

On Apr 13, 2011, at 04:36, Lucas Dixon wrote:
>> I agree with Jacques. My primary argument for applicative functors is
>> diamond import in libraries. Assume you have a set functor in a  
>> library A
>> (e.g. the stdlib). Then there are two seperate libraries B and C,  
>> perhaps
>> from different sources. Both need to use sets. And you want to use  
>> B and C
>> and pass sets from one to the other.
>>
>> Without applicative functors, there are 3 possibilities:
>>
>> 1. Both B and C instantiate the Set functor separately and export  
>> the result
>> -- then you have to convert between the incompatible set types all  
>> the time.
>>
>> 2. Both B and C functorize all their modules over a Set instance --  
>> I think
>> it's obvious that this doesn't scale.
>
> What do you feel is the problem is with scaling this up? (maybe I'm  
> being dumb, but I don't see what the issue is...)

The problem is that you need to turn every module using a functor into  
a functor itself, and eventually end up piling up the entire  
transitive closure of your dependency graph in your functor parameters.

My experience with the early MLKit, which used this so-called "closed  
functor style", was that it is horrible. You need lots of functor  
parameters, lots of structure nesting and reexporting (the sizes of  
signatures can grow exponentially!), and plenty of subtle sharing  
constraints. And when some new code you're writing does not type  
check, you sometimes spend considerable time figuring out whether that  
was a "real" error or you just forgot some type sharing somewhere.

/Andreas