caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Rich Neswold <rich.neswold@gmail.com>
To: Inria Ocaml Mailing List <caml-list@inria.fr>
Subject: Preventing values from escaping a context
Date: Mon, 8 Feb 2010 21:07:22 -0600	[thread overview]
Message-ID: <14cf844b1002081907y2900c313q97ae0cb6f4c92394@mail.gmail.com> (raw)

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

Hello,

I'm writing my first serious Ocaml library and have a question, which I'll
state later on.

Most of the functions in my library take a parameter that describes the
current environment. I call this data type, "context". The context is passed
to a function which will then use other functions in the library to get its
job done. The signature of the function that starts all this is:

val usingContext : (context -> 'a) -> 'a


('usingContext' takes other parameters which are used to create the context
parameter. I dropped them in this example to simplify the problem.)

So 'usingContext' creates a context and passes it to the given function.
'usingContext' will free up the resources of the context whether the
function parameter returns normally, or throws an exception. After cleaning
up the resources, it returns the value returned by the function parameter
(or re-raises the exception.)

My question is this: Is there a way to make the compiler reject a function
parameter from returning the context parameter? For instance, the identity
function should be disallowed since the context is invalid outside the scope
of 'usingContext'. It's true that a returned context would be unusable,
since its resources are gone, but it would be nice to prevent contexts from
escaping the 'usingContext' function entirely.

I'm aware that the ST monad, in Haskell, uses some forall abilities to
prevent stuff from leaving the ST monad. Hopefully there's a way to achieve
this using Ocaml.

(I realize that making this context a monad is a legitimate solution.
However, until I see the Ocaml community including monads in the standard
library, I think I'll stick with idiomatic Ocaml. I'd also like to solve
this functionally, so I'm discounting the use of objects. Sorry for these
constraints!)

Thanks for any help you can provide!

-- 
Rich

Google Reader: https://www.google.com/reader/shared/rich.neswold
Jabber ID: rich@neswold.homeunix.net

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

             reply	other threads:[~2010-02-09  3:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-09  3:07 Rich Neswold [this message]
2010-02-09  3:38 ` [Caml-list] " Jacques Garrigue
2010-02-09  8:24   ` Miles Sabin
2010-02-09  8:43     ` Jacques Garrigue
2010-02-09 17:18     ` Rich Neswold
2010-02-09  8:31   ` Tiphaine Turpin
2010-02-09 18:09     ` Rich Neswold
2010-02-09 18:45       ` Tiphaine Turpin
2010-02-10  0:39         ` Rich Neswold
2010-02-10  8:55           ` Goswin von Brederlow
2010-02-10 18:00             ` Rich Neswold
2010-02-10 21:37               ` Goswin von Brederlow
2010-02-09 17:13   ` Rich Neswold
2010-02-09  3:59 ` Yaron Minsky
2010-02-09 17:16   ` Rich Neswold
2010-02-11 10:39   ` Alexey Rodriguez
2010-02-11 11:05     ` rossberg
2010-02-11 13:52       ` Alexey Rodriguez
2010-02-11 15:17         ` rossberg

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=14cf844b1002081907y2900c313q97ae0cb6f4c92394@mail.gmail.com \
    --to=rich.neswold@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).