From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 852577EE99 for ; Tue, 21 Jan 2014 10:49:41 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.3; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.15.3; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.3; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmICAC5B3lLU4w8DnGdsb2JhbABZuiOFUoEPFg4BAQEBAQYNCQkUKIIlAQEBBDoyChMLGAklDwUoT4dVARi9Vx+GDhePBhaDDoEUBJQ8g2WGMRKPBA X-IPAS-Result: AmICAC5B3lLU4w8DnGdsb2JhbABZuiOFUoEPFg4BAQEBAQYNCQkUKIIlAQEBBDoyChMLGAklDwUoT4dVARi9Vx+GDhePBhaDDoEUBJQ8g2WGMRKPBA X-IronPort-AV: E=Sophos;i="4.95,695,1384297200"; d="scan'208";a="54147321" Received: from mout.web.de ([212.227.15.3]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 21 Jan 2014 10:49:41 +0100 Received: from frosties.localnet ([37.49.32.119]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MLxrY-1VxsSG07X2-007iHr for ; Tue, 21 Jan 2014 10:49:40 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1W5Xxj-0003aY-H8 for caml-list@inria.fr; Tue, 21 Jan 2014 10:49:39 +0100 Date: Tue, 21 Jan 2014 10:49:39 +0100 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20140121094939.GA13578@frosties> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:2pxXSnqsCiQX0nKDlU6/B77pqFmFaQyh159YoLb115djHSP2GCe bSW18x9JsGsvfK09h1ezuWCjo6Dv72MOMq08CcvTSb81JuZX2syUm9AYnLN75Qs8qHSLoIV VNYFWDGOTPq+MLRHSfzQdcCXvSbCjwi6o0FE1VTmmYeUCsdXhq0EpG3G1OemGLfxxbiexvg ZRtyHiUpkzDan5aXXhYPg== Subject: Re: [Caml-list] Purity in ocaml On Mon, Jan 20, 2014 at 03:45:15PM -0500, 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) Does local include the arguments passed to the function? > - 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. Because if arguments don't count this makes no sense. But then shouldn't there be another level for functions that don't alter its arguments? > - 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? > > -Yotam 1) What does pure mean? What does it gain you? How do you want to use it? 2) What syntax do you suggest for annotating functions? 3) Why are exceptions a problem? 4) Will this allow to annotate exceptions too so the compiler can track which exception could be thrown and when all exceptions are caught? If no exception can escape an function then it can be pure again, right? MfG Goswin