caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Dario Teixeira <darioteixeira@yahoo.com>
To: Alexy Khrabrov <deliverable@gmail.com>
Cc: OCaml <caml-list@inria.fr>, "Mikkel Fahnøe Jørgensen" <mikkel@dvide.com>
Subject: The Axis of Eval (was: More cores)
Date: Fri, 19 Dec 2008 07:54:25 -0800 (PST)	[thread overview]
Message-ID: <24075.55485.qm@web111515.mail.gq1.yahoo.com> (raw)
In-Reply-To: <52B31DF4-F49F-41A3-A630-CC9247C2F09C@gmail.com>

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






  reply	other threads:[~2008-12-19 15:54 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-19 13:04 More cores Mikkel Fahnøe Jørgensen
2008-12-19 14:04 ` [Caml-list] " Dario Teixeira
2008-12-19 15:06   ` Alexy Khrabrov
2008-12-19 15:54     ` Dario Teixeira [this message]
2008-12-19 16:26       ` [Caml-list] The Axis of Eval (was: More cores) Paolo Donadeo
2008-12-19 17:01       ` Dario Teixeira
2008-12-19 18:01         ` Christophe Raffalli
2008-12-19 18:50     ` [Caml-list] More cores Ulf Wiger (TN/EAB)
2008-12-19 19:10   ` Richard Jones
2008-12-19 22:31   ` Jon Harrop
2008-12-19 22:36     ` Erik de Castro Lopo
2008-12-19 22:53       ` Jon Harrop
2008-12-22 17:00         ` [Caml-list] More Caml Jon Harrop
2008-12-22 21:44           ` Richard Jones
2008-12-23  6:07             ` Jon Harrop
2008-12-23  9:59               ` Jon Harrop
2008-12-23 15:32                 ` Ashish Agarwal
2008-12-23 17:33                   ` Jon Harrop
2008-12-24 13:12                 ` Mikkel Fahnøe Jørgensen
2008-12-24 16:47                   ` Jon Harrop
2008-12-23 10:04               ` Richard Jones
2008-12-23 10:38                 ` Jon Harrop
2008-12-23  9:43           ` Oliver Bandel
2008-12-23 11:53             ` Jon Harrop
2008-12-19 22:42     ` [Caml-list] More cores Richard Jones
2008-12-20 19:33     ` Mikkel Fahnøe Jørgensen
2008-12-20 19:41       ` Mikkel Fahnøe Jørgensen
2008-12-19 20:37 ` Oliver Bandel
2008-12-19 21:27   ` Richard Jones
2008-12-19 22:03     ` Hezekiah M. Carty
2008-12-19 22:47       ` Richard Jones
2008-12-19 23:00         ` Alexy Khrabrov
2008-12-19 23:56         ` prelude.ml as another standard extension to Pervasives? Alexy Khrabrov
2008-12-20  1:40           ` [Caml-list] " Mikkel Fahnøe Jørgensen
2008-12-20  4:50             ` Alexy Khrabrov
2008-12-20 10:53               ` Zheng Li
2008-12-20 12:37         ` [Caml-list] More cores Richard Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24075.55485.qm@web111515.mail.gq1.yahoo.com \
    --to=darioteixeira@yahoo.com \
    --cc=caml-list@inria.fr \
    --cc=deliverable@gmail.com \
    --cc=mikkel@dvide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).