On Wed, 10 May 2006, 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.

I think phantom types are overkill for this kind of either/or interface.
The method used in the OCaml library of having an in_channel and out_channel
is straightforward enough. Phantom types would make more sense to me
when you have files which can be read and written, with an interface like this

module File :
    sig
      type (-'a) file

      val open_in : string -> [`In] file
      val open_out : string -> [`Out] file
      val open_inout : string -> [`In|`Out] file
      val read : [> `In ] file -> char
      val write : [> `Out ] file -> char -> unit
      val close : 'a file -> unit
    end =
  struct
    (* Implementation omitted *)
  end ;;

Note that I used polymorphic variants or row types to model this, I'm not
sure how to do this cleanly in SML. Of course, you could code it up as
in_channel, out_channel, and inout_channel ;-)

>  A monadic approach (where each
> operation would return a "new" file) or linearity appears necessary for
> the latter.

Yoann Padioleau's suggestion to use the Lisp approach (with-open-file)
looks like the best approach for ML to me.

-- Brian