From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3D2aflV024194 for ; Wed, 13 Apr 2011 04:36:41 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMAANoKpU2B1xBmjmdsb2JhbACmBRQBAQEBCQsJCRIHIMQBhW4E X-IronPort-AV: E=Sophos;i="4.64,201,1301868000"; d="scan'208";a="80682461" Received: from treacle.ucs.ed.ac.uk ([129.215.16.102]) by mail3-smtp-sop.national.inria.fr with ESMTP; 13 Apr 2011 04:36:36 +0200 Received: from lmtp1.ucs.ed.ac.uk (lmtp1.ucs.ed.ac.uk [129.215.149.64]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id p3D2aNaX025924; Wed, 13 Apr 2011 03:36:28 +0100 (BST) Received: from 207-237-107-105.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com (207-237-107-105.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com [207.237.107.105]) (authenticated user=ldixon mech=PLAIN bits=0) by lmtp1.ucs.ed.ac.uk (8.13.8/8.13.7) with ESMTP id p3D2aB1I002068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Apr 2011 03:36:22 +0100 (BST) Message-ID: <4DA50C1B.2070203@inf.ed.ac.uk> Date: Tue, 12 Apr 2011 22:36:11 -0400 From: Lucas Dixon User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: caml-list@inria.fr, rossberg@mpi-sws.org References: <4D9E28D2.1050808@wp.pl> <1302212990.8429.1150.camel@thinkpad> <0F248A34-05CF-4640-B122-75C4CE7C2CD2@mpi-sws.org> <4D9EC172.1060205@lexifi.com> <4D9ECAF2.7070300@lexifi.com> <94bd910fac5bc093e62f73e0ba76d6a1.squirrel@mail.mpi-sws.org> In-Reply-To: <94bd910fac5bc093e62f73e0ba76d6a1.squirrel@mail.mpi-sws.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 X-Scanned-By: MIMEDefang 2.52 on 129.215.149.64 Content-Disposition: inline Subject: Re: [Caml-list] What is an applicative functor? 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.