From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id EBC2E7EE99 for ; Mon, 20 Jan 2014 22:08:30 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of siraaj@khandkar.net) identity=pra; client-ip=63.251.153.119; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="siraaj@khandkar.net"; x-sender="siraaj@khandkar.net"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of siraaj@khandkar.net) identity=mailfrom; client-ip=63.251.153.119; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="siraaj@khandkar.net"; x-sender="siraaj@khandkar.net"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@newguinea.khandkar.net) identity=helo; client-ip=63.251.153.119; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="siraaj@khandkar.net"; x-sender="postmaster@newguinea.khandkar.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAE2P3VI/+5l3/2dsb2JhbABZv2yBK3SCJQEBAQR4EQsYCRYPCQMCAQIBRRMIAQEXh2rEABePBhaEIgEDiUeKdZV+g0s X-IPAS-Result: Ap8EAE2P3VI/+5l3/2dsb2JhbABZv2yBK3SCJQEBAQR4EQsYCRYPCQMCAQIBRRMIAQEXh2rEABePBhaEIgEDiUeKdZV+g0s X-IronPort-AV: E=Sophos;i="4.95,692,1384297200"; d="scan'208";a="45484636" Received: from khandkar.net (HELO newguinea.khandkar.net) ([63.251.153.119]) by mail3-smtp-sop.national.inria.fr with ESMTP; 20 Jan 2014 22:08:29 +0100 Received: from r3-t2.local (pool-71-183-245-233.nycmny.fios.verizon.net [71.183.245.233]) by newguinea.khandkar.net (Postfix) with ESMTPA id C768413E48 for ; Mon, 20 Jan 2014 16:08:26 -0500 (EST) Message-ID: <52DD904B.1000008@khandkar.net> Date: Mon, 20 Jan 2014 16:08:27 -0500 From: Siraaj Khandkar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: caml-list@inria.fr References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Purity in ocaml On 1/20/14 3:45 PM, Yotam Barnoy wrote: > I wanted to gauge the interest of people on the list in adding purity > annotations to ocaml. Purity is one of those things that could really help > with reducing memory allocations through deforestation and decreasing the > running time of programs written in the functional paradigm, and it could > be very useful for parallelism as well. The basic scheme I have in mind is > this: > > - Functions that do not access mutable structures would be marked pure. > - Functions that access only local mutable structures would be marked as st > (a la state monad) > - Functions that access global mutable data would be unmarked (as they are > now). > - Pure functions can call st functions/code so long as all of the state > referred to by the st code is contained within said pure functions. > - Functions that call higher order functions, but do not modify mutable > state would be marked hpure (half-pure). These functions would be pure so > long as the functions they call remain pure. This allows List.map, > List.fold etc to work for both pure and impure code. > - The same thing exists for st code: hst represents functions that take > higher order functions but only performs local state mutation. > - In order to take advantage of this mechanism, there's no need to annotate > functions. The type inference algorithm will figure out the strictest type > that can be applied to a function and will save the annotation to an > external, saved annotation file. This means that non-annotated code can > take advantage of purity without doing any extra work, and the programmer > never has to think about purity. > - Having the purity annotations as an option is useful to force certain > parts of the code, such as monads, to be pure. > - An edge case: local state can be made to refer to global state by some > external function call. Therefore, local state is considered 'polluted' > (and global) if it is passed to an impure function. > - Exceptions: not sure how to handle them yet. The easiest solution is to > forbid them in st/pure code. Another easy alternative is to only allow > catching them in impure code, as haskell does. > > Thoughts? Exceptions was the first thought that came to mind when I began reading this - I think the ability to track unhandled exceptions, which I think OcamlPro is working on, is a pre-req for any purity analysis to be meaningful, since so many, otherwise pure, structures raise exceptions :/