From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3F399fP022974 for ; Fri, 15 Apr 2011 05:09:09 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAPS1p02B1w3NkWdsb2JhbACmARQBAQEBCQsLBxQFIIhvvCmFbgQ X-IronPort-AV: E=Sophos;i="4.64,215,1301868000"; d="scan'208";a="96983047" Received: from nougat.ucs.ed.ac.uk ([129.215.13.205]) by mail2-smtp-roc.national.inria.fr with ESMTP; 15 Apr 2011 05:09:03 +0200 Received: from lmtp1.ucs.ed.ac.uk (lmtp1.ucs.ed.ac.uk [129.215.149.64]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id p3F38lLQ027434; Fri, 15 Apr 2011 04:08:57 +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 p3F38kvd012648 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 15 Apr 2011 04:08:47 +0100 (BST) Message-ID: <4DA7B6BE.8090605@inf.ed.ac.uk> Date: Thu, 14 Apr 2011 23:08:46 -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: Andreas Rossberg CC: caml-list@inria.fr 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> <4DA50C1B.2070203@inf.ed.ac.uk> <7123693C-B554-4944-9234-EA5E465E42B1@mpi-sws.org> In-Reply-To: <7123693C-B554-4944-9234-EA5E465E42B1@mpi-sws.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 X-Scanned-By: MIMEDefang 2.52 on 129.215.149.64 Content-Disposition: inline Subject: Re: [Caml-list] What is an applicative functor? On 13/04/2011 03:23, Andreas Rossberg wrote: > 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. yes, the concept of module for SML is really a functor and dependencies are explicit. > 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. My feeling was that a little improvement on the syntax of signatures and sharing would deal with these issues fairly easily. In terms of growing exponentially: that sounds like a serious problem; I would expect it to grow linearly on the number of dependencies. Or did you mean to use exponentially informally; as in gets too bug too quick? > 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. I ended up pushing improvements to the type-error printing which helped a lot in PolyML. That combined with a finding a style that works out not too hideously: I create a sub-structure, typically called "Sharing" to hold just types that are relevant to a particular module. I can then use sharing on this substructure to share all types and save the others painful problem to remember to share every type. For example, see basic_graph.ML in Quantomatic code (a graph rewriting tool in SML): http://isaplanner.svn.sourceforge.net/viewvc/isaplanner/trunk/quantomatic/core/graph/basic_graph.ML?revision=3017&view=markup So my basic feeling is still that this is an issue of finding a little syntax sugar and then the functorial style could work well... (with the sub-structure style I find it bearable, and can even enjoy using functors). I guess the prerogative is to write that sugar and then try re-tasting the functorial soup. best, lucas -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.