From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p38IjBKl000349 for ; Fri, 8 Apr 2011 20:45:11 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUAABxXn02LEwExkWdsb2JhbACmKQEBAQEJCwsHFAUgiHqqfgGNXgWFbQ X-IronPort-AV: E=Sophos;i="4.63,325,1299452400"; d="scan'208";a="92554579" Received: from infao0809.mpi-sb.mpg.de (HELO hera.mpi-sb.mpg.de) ([139.19.1.49]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 08 Apr 2011 20:45:05 +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=LfYcMZnzD1HCxK1X+6kEXgFIiVm/OkpcjXvv5oU v3o0=; b=AD9FUDiLC/bokyTXLjmzpUFma00DluJDMeFGuDppMf86nKBLX896Hlh GqvPAD3ppfVaE8tS0mmvpxHma4QI8F6pB3Jbq2ZJhM4FFj5iXO5Xz0PhJtP+AaCj y3dWNVWosDzdhm4vSwhPupX6ZUGJsnnkXsaO82LkEfWnHi2mI1NA= Received: from zak.mpi-klsb.mpg.de ([139.19.1.27]:49735) by hera.mpi-sb.mpg.de (envelope-from ) with esmtp (Exim 4.69) id 1Q8Gfw-0006of-F4; Fri, 08 Apr 2011 20:44:58 +0200 Received: from mnch-5d86c5a4.pool.mediaways.net ([93.134.197.164]:63052 helo=[192.168.178.22]) by zak.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) id 1Q8Gfv-0007VI-Kq; Fri, 08 Apr 2011 20:44:55 +0200 From: Andreas Rossberg To: Till Varoquaux In-Reply-To: References: <4D9E28D2.1050808@wp.pl> <1302212990.8429.1150.camel@thinkpad> <0F248A34-05CF-4640-B122-75C4CE7C2CD2@mpi-sws.org> 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: Fri, 8 Apr 2011 20:44:54 +0200 Cc: Gerd Stolpmann , Dawid Toton , caml-list X-Mailer: Apple Mail (2.936) Subject: Re: [Caml-list] What is an applicative functor? On Apr 8, 2011, at 18:43, Till Varoquaux wrote: > I tend to consider using Impure functors as very poor coding hygiene.. > I am sure there are compelling use cases but I've yet to come across > one. Providing safer types for impure functors does not seem > compelling enough to justify having several kind of functors. Alain gave a good example. An even simpler one is a generator for a type of abstract names. There are a number of others, e.g. modules accessing external resources. Even more uses potentially arise with first-class modules, which can take the role of powerful (probably stateful) objects, with functors being their constructors. > I am not really sure I want applicative functors (based upon my > experience they are pretty hard to explain and rarely buy me anything) > but I balk at the idea of having both applicative and generative > functors.. It doesn't have to be complicated, especially not for the user. Admittedly, previous approaches providing both made it much more complicated than necessary, with duplicated syntax and all -- all you really need is to have the type system track whether a module is pure. We have a relatively elegant formulation of such a system in our F-ing Modules framework (I just have to find the time to write that paper). I don't think that pure functors are incredibly hard to explain either -- after all, even C++ programmers find them natural. Of course, terminology like "applicative" or "generative" is less helpful then it has to be. /Andreas