From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 88E86BBAF for ; Fri, 19 Dec 2008 16:54:28 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.36,249,1228086000"; d="scan'208";a="32893389" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 19 Dec 2008 16:54:28 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id mBJFsRDe002857 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 19 Dec 2008 16:54:28 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiADAPJSS0lDww/ZlGdsb2JhbACOQ4UhAQEBAQkLCAkRA6s1WINUjRAFAgGDAA X-IronPort-AV: E=Sophos;i="4.36,249,1228086000"; d="scan'208";a="21529485" Received: from web111515.mail.gq1.yahoo.com ([67.195.15.217]) by mail1-smtp-roc.national.inria.fr with SMTP; 19 Dec 2008 16:54:27 +0100 Received: (qmail 56489 invoked by uid 60001); 19 Dec 2008 15:54:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=mlvcvTFwtSzGs9DnouPrToyecENB6bX1vNRbTDiSH50AclA/tY00pbFGATbTBGT1ODFny5A37lcPWU4Ev3yOc31Oum3wV8QAbILRZNiDW+JiF0tUJs1OGO2hnDgeLOISoLd9IJrL37uNx5atUvmLBzGY/nW41CgnZizTwnHwsZw=; X-YMail-OSG: _tfTz.MVM1ljl0S_RJVnIsjVIJOGgD3FQWyQmmHv0yLjWsrEfGusGV43F4rLOVpgjvyypA5XOnGhTpqqkMXefD0yBj78CwBXTejU1F3TrZk8PE2bzPScfIJkxqB9sHbYnZVk397M1DSKz6brCwqAzdkLc6Toibxlqh7hE.0JBYNFZ6w- Received: from [213.205.71.56] by web111515.mail.gq1.yahoo.com via HTTP; Fri, 19 Dec 2008 07:54:25 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Fri, 19 Dec 2008 07:54:25 -0800 (PST) From: Dario Teixeira Subject: The Axis of Eval (was: More cores) To: Alexy Khrabrov Cc: OCaml , =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= In-Reply-To: <52B31DF4-F49F-41A3-A630-CC9247C2F09C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24075.55485.qm@web111515.mail.gq1.yahoo.com> X-Miltered: at concorde with ID 494BC3B3.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; erlang:01 ocaml:01 model:01 ocaml's:01 ocaml:01 ocamlexc:01 val:01 val:01 haskell:01 monads:01 cheers:01 eclectic:98 embrace:98 threads:01 integer:01 Hi, > Erlang makes concurrency easy due to purity, and OCaml is > famous for being eclectic. Why not embrace Erlang's > model by imposing limitations on what can be in threads -- > keeping them pure? Indeed. Ocaml's imperative features can be very useful in a local context (ie, not crossing the boundaries of a function), but do hinder concurrency when used for modifying global state. I wonder: is there already a tool that verifies Ocaml code to ensure that a function is pure? Something along the lines of Ocamlexc, but applied to purity. The way I see it, there are (at least) three axis associated with a function: the value axis, the exception axis, and the purity axis (the latter can also be called the side-effect axis). In Ocaml, a function signature cares only about the value axis, though implicitly the other axis are also be present. For example: val integer_division: int -> int -> int throws Division_by_zero is_pure val incr_global_counter: unit -> unit throws_nothing is_not_pure I can imagine a "spawn" statement in a concurrent Caml that expects that the function passed as parameter be pure. And of course a function would only be pure if it did not modify global state and only invoked pure functions itself. Obviously the other alternative is to go the Haskell route and transform Caml in a pure functional language where monads reign. Though I think it would be interesting to come up with a solution that keeps the advantages of local imperative features, but does ensure purity for the purpose of concurrency. (and I'm sure there is already a ton of research along these lines) Cheers, Dario Teixeira =0A=0A=0A