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.