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 p3JE55tT005166 for ; Tue, 19 Apr 2011 16:05:05 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkAAIaVrU2LEwExe2dsb2JhbAClKxQBARYmBSCIb61tAY4oBYVxm1Y X-IronPort-AV: E=Sophos;i="4.64,239,1301868000"; d="scan'208";a="81360577" Received: from hera.mpi-sb.mpg.de ([139.19.1.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 19 Apr 2011 16:05:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=From:To:In-Reply-To:Subject: References:Message-Id:Content-Type:Content-Transfer-Encoding: Mime-Version:Date:Cc; bh=VXz/1vjHBqin5KJCDXKVM4mI+U+DEDOWUkO4B+8 ehl0=; b=taU9dqJVmQnGVnCd3QAV3ZKoarry5Ss+XSstyLLyIOU/e2VWfQIwcK/ yBI/guL4ilUx3gjzHCDfJF40dH63u6JhL0dvusKsLctki9ji9roxx/SYSa7vhyI9 gHRq7WxPeq11hHaTZyBEdeBw4S5ibv1JENfW4p3T/CqKmLB6bZVI= Received: from maniac.mpi-klsb.mpg.de ([139.19.1.26]:34182) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1QCBY0-0007jU-VU; Tue, 19 Apr 2011 16:04:59 +0200 Received: from mnch-5d87aa86.pool.mediaways.net ([93.135.170.134]:64635 helo=[192.168.178.31]) by maniac.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) id 1QCBXz-0003sL-DL; Tue, 19 Apr 2011 16:04:56 +0200 From: Andreas Rossberg To: Lucas Dixon In-Reply-To: <4DA7B6BE.8090605@inf.ed.ac.uk> 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> <4DA7B6BE.8090605@inf.ed.ac.uk> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 19 Apr 2011 16:04:50 +0200 Cc: caml-list@inria.fr X-Mailer: Apple Mail (2.936) Subject: Re: [Caml-list] What is an applicative functor? On Apr 15, 2011, at 05.08 h, Lucas Dixon wrote: > On 13/04/2011 03:23, Andreas Rossberg wrote: >> 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. I think this is very much a semantic problem, but I still would be interested to hear what improvements you have in mind. > 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? No, I meant it literally. One common idiom with functors is to re- export all parameter structures in the result, in order to have a self- contained result signature (and ease sharing later on). When you continue doing that up the entire dependency graph, then signatures can grow exponentially (in the depth of the dependency chain). >> 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. Sure, such idioms can help, but I don't think they solve the general problem. The more dependencies you have (e.g. in some more top-level module) the more unstructured their relations become, and it is difficult to organize them in a useful way. In a way, parameterizing out all imports is a kind of manual closure conversion. You wouldn't want to be forced to doing that in the small, and I don't see why you should in the large. I feel that it also exposes too much of what should be considered implementation details. > yes, the concept of module for SML is really a functor and > dependencies are explicit. I guess the underlying question is what constitutes a module? I think you have to distinguish modules (as individual abstractions) from components/libraries/packages/whatever you like to call them. The latter can consist of many modules. In that spectrum, there is a place for both definite and indefinite references to other modules. You often want the the latter when you cross boundaries to other libraries. But the current functor mechanism is not an adequate means for expressing them, because it cannot be used at that level. /Andreas