Lambda the Ultimate

Neither of your suggestions works properly. RAII only works in C++ because most programs are predominently first-order (and it still isn't safe) - it is not an option in a high-level language where closures are omnipresent and life time is not bounded by lexical scope. A with_* style function may help to prevent simple accidents, but also isn't safe, since nothing prevents a client from returning the surface from the argument function. That is, in both cases the resource could be accessed after it has been released.

...here's a simple example illustrating Andreas's point:

  val with_surface : (surface → 'a) → 'a 

  let bogus : surface = with_surface (fun x → x)

So by instantiating the polymorphic type at type surface, you can pass it the identity function to get ahold of a deallocated surface.

We're talking about an IO-oriented library here... You could always make sure the function returns (), if side effects are typed. In the general case, that doesn't work, of course.

Returning () would be quite constrained, even for I/O — it may work for the O side, but certainly not for the I side, where you usually want to get back some useful information.

Thanks for the explanation - I appreciate it

References are very powerful!

  val with_surface : (surface → unit) → unit

  let stash = ref None  

  let evil(surface) = (stash := Some surface)

  let bogus : surface = begin
     with_surface evil;
     let Some(s) = !stash in
     s
   end

True, but pkhuong was careful to say "if side-effects are typed". In that case, I assume, your `evil' would not return type () as such. Although in that case, you probably cannot use the approach for I/O either.

...of references that's the problem. Even if we give this API a monadic type, a monadic program can still get ahold of a stale reference:

   val with_surface : (surface → IO unit) → IO unit

   let bogus : IO(surface) = 
     do stash ← ref None;
        let evil(s) = stash := Some None;
        () ← with_surface(evil);
        Some(s) ← !stash;
        return s

Something like Haskell's runST would probably work, in which you add an extra index to the monad to tag the region of the heap the program should act on, and require the argument to be polymorphic in the region. But this isn't that simple; we're really nearing the point where linear types are just as easy to implement, and likely more flexible in practice.

Yes to all that, but I was interpreting the parent post as suggesting that the user function has to return pure type unit, and not IO unit or anything similar, which would rule out any such examples (while also making the idea useless for I/O).

PS: hey, why unicodify your left arrows, but not the right ones? :-)

I figured he couldn't mean that, since it would be useless for IO. :)

Anyway, I unicoded the left arrows since leading left-angle brackets trigger HTML parsing nonsense. But there's no reason not to unicode both arrows, so I changed them all. :)

What's weird is that, on my Mac at least, the larr's appear to be twice as long as the rarr's. 8-} Does the Courier font include right arrows, but not left arrows?

the reason is that computers suck, i think. on this mac + ff, they look to be the same size to me.

Something like Haskell's runST would probably work, in which you add
an extra index to the monad to tag the region of the heap the program
should act on, and require the argument to be polymorphic in the
region. But this isn't that simple; we're really nearing the point
where linear types are just as easy to implement, and likely more
flexible in practice.

Something like Haskell's ST does indeed work, and it is that simple --
provided our regions are isolated. However, often we would like to
access reference cells/file descriptors of parent regions in child
regions. Also, we would like to avoid imposing the total order on
parent regions. Even that is not enough for practical programs -- for
example, a child region may want to allocate a file descriptor in a
parent region, so that it can return it or put in a reference
cell. All these points have been described in the Lightweight Monadic
Regions paper (Haskell Symposium, 2008). The implementation --
surprisingly quite simple -- is available on Hackage and has been used
in a Safe USB library by Bas van Dijk:

http://hackage.haskell.org/package/usb-safe-0.4

Haskell already has all the required machinery for the discussed
facility (safe IO), and it seems quite easy to implement and use.