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 6B7E67EE99 for ; Mon, 20 Jan 2014 21:45:37 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.216.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.216.51 as permitted sender) identity=mailfrom; client-ip=209.85.216.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qa0-f51.google.com) identity=helo; client-ip=209.85.216.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qa0-f51.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8CAM2J3VLRVdgzlGdsb2JhbABZhBm8XggWDgEBAQEHCwsJEiqCbAEbHgMSCQddAREBBQEiLodVAQMRmGKDCIxcgwmSBAoZJw1khHIRAQUMkzIEiUeKdYNmkCsYKYR3Hg X-IPAS-Result: As8CAM2J3VLRVdgzlGdsb2JhbABZhBm8XggWDgEBAQEHCwsJEiqCbAEbHgMSCQddAREBBQEiLodVAQMRmGKDCIxcgwmSBAoZJw1khHIRAQUMkzIEiUeKdYNmkCsYKYR3Hg X-IronPort-AV: E=Sophos;i="4.95,691,1384297200"; d="scan'208";a="54078824" Received: from mail-qa0-f51.google.com ([209.85.216.51]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Jan 2014 21:45:36 +0100 Received: by mail-qa0-f51.google.com with SMTP id f11so5844900qae.38 for ; Mon, 20 Jan 2014 12:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=M1twf5oK3sxiJnGRFENN9SD7OPzSQaSzBBiJYLGPHNE=; b=MksC2FL64zpf1mkpBAamApJf5xDfGc/XaNRLc+3SuzuPmUEByI92vYt96tl9NbHvFq KXHgRZBTA5yJ1KNpFFNpNHt3DgybEVQSu2BSBJlze2wkr+LwmyqubKeC1EqI1XS4IFoY D7UaODiur8+zYiiGgI9Ngu6YVA7ZfWunZaNMhkFbH8VWOo0ARF+EzYfTpnnkrNcdUmmo 9UiOQFH6tSF05l+391d2g7TeWlsfRdNfxmlLX020UTa7uUBIrlDLDtVDXLaytrpQj2Y/ +77PqSCu88INvlh89wEgen+BW+61gtS68NTv/aNwpddHO9/Asi4VS43KdblDh8TlRSsT tMhQ== X-Received: by 10.224.127.74 with SMTP id f10mr31563995qas.56.1390250735277; Mon, 20 Jan 2014 12:45:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.95.8 with HTTP; Mon, 20 Jan 2014 12:45:15 -0800 (PST) From: Yotam Barnoy Date: Mon, 20 Jan 2014 15:45:15 -0500 Message-ID: To: Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a11c2cc18399e7f04f06cf92d Subject: [Caml-list] Purity in ocaml --001a11c2cc18399e7f04f06cf92d Content-Type: text/plain; charset=ISO-8859-1 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? -Yotam --001a11c2cc18399e7f04f06cf92d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I w= anted to gauge the interest of people on the list in adding purity annotati= ons to ocaml. Purity is one of those things that could really help with red= ucing memory allocations through deforestation and decreasing the running t= ime of programs written in the functional paradigm, and it could be very us= eful 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 th= e state referred to by the st code is contained within said pure functions.=
- Functions that call higher order functions, but do not modify m= utable state would be marked hpure (half-pure). These functions would be pu= re so long as the functions they call remain pure. This allows List.map, Li= st.fold etc to work for both pure and impure code.
- The same thing exists for st code: hst represents functions that ta= ke higher order functions but only performs local state mutation.
= - In order to take advantage of this mechanism, there's no need to anno= tate 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 e= xternal, 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 certa= in 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 i= s to forbid them in st/pure code. Another easy alternative is to only allow= catching them in impure code, as haskell does.

Thoughts?

-Yotam
--001a11c2cc18399e7f04f06cf92d--