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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 924C0BB86 for ; Wed, 10 May 2006 20:48:07 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4AIm7xF022662 for ; Wed, 10 May 2006 20:48:07 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA24341 for ; Wed, 10 May 2006 20:48:06 +0200 (MET DST) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.193]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4AIm5VX022649 for ; Wed, 10 May 2006 20:48:06 +0200 Received: by wx-out-0102.google.com with SMTP id t12so1374689wxc for ; Wed, 10 May 2006 11:48:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lhbenr/F4yHDIyn4y9kONika3Rtj9pCgIOsjaFqcLCdtnNSRKxnh+35jo+Z5tPfRWD6AF+bng0pBJL3g3GNhWC9ZaurZ+DZ1sEVtyRNMy2vtNmTBe8njMn02Ln2gFaqm7n9v9Q2z7438qvQILGfQQfzUV6rBzwO/TqN3D3olyuI= Received: by 10.70.103.14 with SMTP id a14mr916953wxc; Wed, 10 May 2006 11:47:55 -0700 (PDT) Received: by 10.70.128.20 with HTTP; Wed, 10 May 2006 11:47:55 -0700 (PDT) Message-ID: <9d3ec8300605101147j2f108aiab06820a9e77408@mail.gmail.com> Date: Wed, 10 May 2006 20:47:55 +0200 From: "Till Varoquaux" To: Shawn Subject: Re: [Caml-list] Re: OO design Cc: caml-list@inria.fr In-Reply-To: <44623257.1060000@speakeasy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <53c655920605050235k64e70333je8df813239ea3c53@mail.gmail.com> <20060508.121743.65190532.garrigue@math.nagoya-u.ac.jp> <200605082329.36911.David.Teller@ens-lyon.org> <445FB9C7.4040703@cs.washington.edu> <446152CB.5010605@cis.upenn.edu> <44621204.4020601@cs.washington.edu> <44623257.1060000@speakeasy.org> X-j-chkmail-Score: MSGID : 44623565.000 on nez-perce : j-chkmail score : X : 0/20 1 X-Miltered: at nez-perce with ID 44623567.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44623565.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocamlnet:01 netchannels:01 cheers:01 shawnw:01 val:01 val:01 enforces:01 monadic:01 beginner's:01 ocaml:01 beginners:01 bug:01 wrote:01 wrote:01 sourceforge: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.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.3 One rather standard way to preserve atomicity of open/close operation is to use with... commands: let with_open_out filename f =3D let chan =3D open_out filename in let res=3D(try f chan with e -> close_out chan; raise e) in close_out chan; res Where f is the function you want to use to generate f's content (takes an out_channel). This forces chan to be closed no matter what happens. You may also want to have a look at ocamlnet's channel's implementation (it's OO and might do a lot of you are looking for): http://ocamlnet.sourceforge.net/refman/Netchannels.html Cheers, Till On 5/10/06, Shawn wrote: > Dan Grossman wrote: > > > > I totally agree -- effects limit the class of protocols you can > > enforce, but I believe (please correct me if I've missed a dirty > > trick) the "simple stuff" still works fine. For example: > > > > type read; > > type write; > > type 'a file; > > val open_r : string -> read file; > > val open_w : string -> write file; > > val write : write file -> char -> unit; > > val read : read file -> char; > > val close : 'a file -> unit; > > > > It enforces that you don't confuse your reads and writes, but *not* > > that you don't use a file after you close it. A monadic approach > > (where each operation would return a "new" file) or linearity appears > > necessary for the latter. > How can an approach like this handle files opened for reading and > writing at the same time? Hmm. Maybe an OO approach? readable_file and > writable_file classes, and a read_write_file that inherits from both. > It'd be easy to add new file-like types too. I'm not normally a big fan > of OO, but this is a place where it seems to make sense to use. Of > course, it doesn't do anything about the compile time checking of > attempts to use a closed file either. > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >