caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Philippe Veber <philippe.veber@gmail.com>
To: caml users <caml-list@inria.fr>
Subject: [Caml-list] Not letting channels escape.
Date: Fri, 8 Aug 2014 12:23:53 +0200	[thread overview]
Message-ID: <CAOOOohRCFcHLsgkpVrknKcQG1asP6WwUwvwmMuZbPV72gitL+g@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

Dear all,

many libraries like lwt, batteries or core provide a very nice idiom to be
used when a function uses a resource (file, connection, mutex, et cetera),
for instance in Core.In_channel, the function:

val with_file : ?binary:bool -> string -> f:(t -> 'a) -> 'a

opens a channel for [f] and ensures it is closed after the call to [f],
even if it raises an exception. So these functions basically prevent from
leaking resources. They fail, however, to prevent a user from using the
resource after it has been released. For instance, writing:

input_char (In_channel.with_file fn (fun x -> x))

is perfectly legal type-wise, but will fail at run-time. There are of
course less obvious situations, for instance if you define a function:

val lines : in_channel -> string Stream.t

then the following will also fail:

Stream.iter f (In_channel.with_file fn lines)

My question is the following: is there a way to have the compiler check
resources are not used after they are closed? I presume this can only be
achieved by strongly restricting the kind of function passed to
[with_file]. One simple restriction I see is to define a type of immediate
value, that roughly correspond to "simple" datatypes (no closures, no lazy
expressions):

module Immediate : sig
  type 'a t = private 'a
  val int : int -> int t
  val list : ('a -> 'a t) -> 'a list -> 'a list t
  val tuple : ('a -> 'a t) -> ('b -> 'b t) -> ('a * 'b) -> ('a * 'b) t
  (* for records, use the same trick than in
http://www.lexifi.com/blog/dynamic-types *)
  ...
end

and have the type of [with_file] changed to

val with_file : string -> f:(in_channel -> 'a Immediate.t) -> 'a

I'm sure there are lots of smarter solutions out there. Would anyone happen
to know some?

Cheers,
  Philippe.

[-- Attachment #2: Type: text/html, Size: 2156 bytes --]

             reply	other threads:[~2014-08-08 10:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08 10:23 Philippe Veber [this message]
2014-08-08 11:22 ` Peter Zotov
2014-08-08 11:30 ` Ben Millwood
2014-08-08 14:49   ` Ben Millwood
2014-08-08 15:44     ` Markus Mottl
2014-08-08 16:01       ` Ben Millwood
2014-08-08 17:21         ` Markus Mottl
2014-08-08 17:37           ` Gabriel Scherer
2014-08-08 18:23             ` Markus Mottl
2014-08-08 18:28               ` Frédéric Bour
2014-08-08 19:30                 ` Markus Mottl
2014-08-08 19:45                   ` Frédéric Bour
2014-08-08 20:34                     ` Markus Mottl
2014-08-10 18:06                       ` Philippe Veber
2014-08-11  9:07                     ` Ben Millwood
2014-08-11 15:26                       ` Goswin von Brederlow

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=CAOOOohRCFcHLsgkpVrknKcQG1asP6WwUwvwmMuZbPV72gitL+g@mail.gmail.com \
    --to=philippe.veber@gmail.com \
    --cc=caml-list@inria.fr \
    /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).