From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id AC89FBB81 for ; Tue, 7 Mar 2006 17:51:29 +0100 (CET) Received: from gw-eur4.philips.com (gw-eur4.philips.com [161.85.125.10]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k27GpTL1023750 for ; Tue, 7 Mar 2006 17:51:29 +0100 Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com [130.144.57.168]) by gw-eur4.philips.com (Postfix) with ESMTP id CF22B4972C; Tue, 7 Mar 2006 16:51:28 +0000 (UTC) Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id A311C3D; Tue, 7 Mar 2006 16:51:28 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP id 7BAC23B; Tue, 7 Mar 2006 16:51:28 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id 4A4F933; Tue, 7 Mar 2006 16:51:28 +0000 (GMT) In-Reply-To: <440DB255.1030701@asfandyar.cjb.net> To: caml-list@yquem.inria.fr Cc: Asfand Yar Qazi Subject: Re: [Caml-list] STM support in OCaml MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Sebastian Egner Date: Tue, 7 Mar 2006 17:50:11 +0100 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.3FP1HF291 | September 19, 2005) at 07/03/2006 17:50:14, Serialize complete at 07/03/2006 17:50:14 Content-Type: multipart/alternative; boundary="=_alternative 005C995CC125712A_=" X-Miltered: at concorde with ID 440DBA11.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 library':01 arrays:01 haskell:01 enclosing:01 semantics:01 library':01 arrays:01 haskell:01 enclosing:01 semantics:01 herself:98 herself:98 caml-list:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=HTML_30_40,HTML_MESSAGE autolearn=disabled version=3.0.3 This is a multipart message in MIME format. --=_alternative 005C995CC125712A_= Content-Type: text/plain; charset="US-ASCII" > Are there any plans to add STM to OCaml? And I'm talking highly integrated > into the language, not just some bolt-on library. I implemented 'some bolt-on library' as you call it for myself (for understanding the details of STM) but did not release it. The main lesseons I learned, however, are a) A library will be nearly as good as something 'highly integrated into the language'. The main difference is that you cannot annotate fields to be transactional, and define transactional record types; you need to work with explicit transactional reference boxes and arrays. This appears tolerable, and it is a lot simpler, both in terms of implementation and in terms of using it. b) The version of STM as designed for Haskell makes essential use of laziness for composing transactions in a very clean way. You can construct more and more complex transactions by not yet enclosing them into 'atomic'. This is probably the most important benefit of STMs at all. Unfortunately, this property is essentially impossible in OCaml: No matter how highly integrated STMs are in the language, it will always be easy to write a program that uses ordinary (non-STM) state to keep a record of something it shouldn't---messing up semantics of course. Sorry, I know this is bad news, but that is what I found. I invite everybody to verify this for him- or herself, or prove me wrong. Sebastian. --=_alternative 005C995CC125712A_= Content-Type: text/html; charset="US-ASCII"
> Are there any plans to add STM to OCaml?  And I'm talking highly integrated
> into the language, not just some bolt-on library.

I implemented 'some bolt-on library' as you call it for
myself (for understanding the details of STM) but did
not release it. The main lesseons I learned, however, are

a) A library will be nearly as good as something 'highly
integrated into the language'. The main difference is
that you cannot annotate fields to be transactional,
and define transactional record types; you need to
work with explicit transactional reference boxes and arrays.
This appears tolerable, and it is a lot simpler, both in
terms of implementation and in terms of using it.

b) The version of STM as designed for Haskell makes essential
use of laziness for composing transactions in a very clean
way. You can construct more and more complex transactions
by not yet enclosing them into 'atomic'. This is probably
the most important benefit of STMs at all. Unfortunately,
this property is essentially impossible in OCaml: No matter
how highly integrated STMs are in the language, it will
always be easy to write a program that uses ordinary (non-STM)
state to keep a record of something it shouldn't---messing
up semantics of course.

Sorry, I know this is bad news, but that is what I found.
I invite everybody to verify this for him- or herself,
or prove me wrong.

Sebastian. --=_alternative 005C995CC125712A_=--