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

[Lucas Dixon <ldixon@inf.ed.ac.uk>]

Hi,

On 08/04/2011 09:43, rossberg@mpi-sws.org wrote:
>> On 04/08/2011 10:20 AM, Jacques Garrigue wrote:
>>> Applicative functors have other advantages, like the fact you can refer to
>>> a
>>> type produced by a functor without having really applied it.
>
> 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...)

I see that you have to pay some syntax for using functors that share a 
Set, and for later functors that build on B or C. You can make a 
sub-structure for the types you use, and then a bit of signature sharing 
magic, and it can be done fairly reasonably, I think.

It does seem to me that if your type is always going to be the same, 
then you can just define it first, and then parametrise what you do with 
it... or even just refer to it later...

A fun idea is to provide some syntax for implicit module 
parametrisation: have a union-style semantics for when overlapping 
implicit modules are imported. (just some lightweight syntax for the above).

But do you think there is an implementational problem with this 
functorisation in terms of scaling it up?

I've built a fairly large (for SML, it's 40k lines) of fairly heavily 
functorised code (approx 10 functors deep), essentially using this 
approach. It pushes the PolyML compiler a bit, and requires some 
slightly frustrating extra 'Sharing'-substructures, but otherwise works 
ok. The sharing substructures would disappear if we had a sensible 
signature language.

best,
lucas

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.