caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Dan Grossman <djg@cs.washington.edu>
To: Geoffrey Alan Washburn <geoffw@cis.upenn.edu>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Re: OO design
Date: Wed, 10 May 2006 09:17:08 -0700	[thread overview]
Message-ID: <44621204.4020601@cs.washington.edu> (raw)
In-Reply-To: <446152CB.5010605@cis.upenn.edu>


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.

--Dan

Geoffrey Alan Washburn wrote:
> Dan Grossman wrote:
> 
>> Phantom types are a programming idiom that can often pull off this 
>> sort of thing.
> 
> 
>     Maybe I'm just not smart enough, but I can't seem to think of a way 
> to do this in an effectful language without getting bitten by aliasing.  
> In a purely functional setting, a monadic approach seems plausible, but 
> if you can create a "ref" anywhere, as in OCaml, it seems 
> straightforward to subvert any uses of phantom types for implementing 
> protocols.  I suppose one could look at it from the angle that phantom 
> types make it harder for cooperative users to make mistakes, but I can't 
> see how they can prevent the need for runtime checks.
> 
> _______________________________________________
> 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


  reply	other threads:[~2006-05-10 16:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05  9:35 David Baelde
2006-05-05 10:47 ` [Caml-list] " Gerd Stolpmann
2006-05-05 13:00 ` Remi Vanicat
2006-05-05 19:32   ` Andrej Bauer
2006-05-08  3:17 ` Jacques Garrigue
2006-05-08 21:29   ` David Teller
2006-05-08 21:36     ` Dan Grossman
2006-05-10  2:41       ` Geoffrey Alan Washburn
2006-05-10 16:17         ` Dan Grossman [this message]
2006-05-10 18:15           ` Geoffrey Alan Washburn
2006-05-10 18:44             ` [Caml-list] " Dan Grossman
2006-05-10 18:35           ` Shawn
2006-05-10 18:47             ` Till Varoquaux
2006-05-10 19:01               ` Shawn
2006-05-10 18:43           ` brogoff
2006-05-11  0:08             ` Geoffrey Alan Washburn
2006-05-11  5:45               ` [Caml-list] " Till Varoquaux
2006-05-11  6:21               ` Jacques Garrigue
2006-05-11 15:48                 ` Geoffrey Alan Washburn

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=44621204.4020601@cs.washington.edu \
    --to=djg@cs.washington.edu \
    --cc=caml-list@inria.fr \
    --cc=geoffw@cis.upenn.edu \
    /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).