Db and STRef

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Db and STRef

Brandon Moore
John Goerzen wrote:
...
> I didn't honestly follow the STRef discussion, or how something so
> I/O-based could work there.
>
> -- John

The only message I've found was Oleg mentioning the typing that keeps
an STRef limited to the scope of the runST it came from.

I don't think database access could live in ST either.
I think the proposal was to build something like Oleg's Monadic Regions
http://okmij.org/ftp/Haskell/types.html#monadic-regions
on top of IO

I'm assuming you understand how the type on runST and the STRef
operations ensure that, even though you *can* smuggle out an STRef in
the result from runST, you will never be able to use it again.

The idea was to do the equivalent thing with databases: use fancy types
to ensure that handle can only be used inside to origination withDB or
withCursor or whatever, and the bracketing function can release the
resource on the way out, without worrying about it being used again.

Brandon

> _______________________________________________
> Haskell mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Db and STRef

Ben Franksen-2
On Sunday 15 January 2006 19:50, Brandon Moore wrote:

> John Goerzen wrote:
> ...
>
> > I didn't honestly follow the STRef discussion, or how something so
> > I/O-based could work there.
> >
> > -- John
>
> The only message I've found was Oleg mentioning the typing that keeps
> an STRef limited to the scope of the runST it came from.
>
> I don't think database access could live in ST either.
> I think the proposal was to build something like Oleg's Monadic
> Regions http://okmij.org/ftp/Haskell/types.html#monadic-regions
> on top of IO
>
> I'm assuming you understand how the type on runST and the STRef
> operations ensure that, even though you *can* smuggle out an STRef in
> the result from runST, you will never be able to use it again.
>
> The idea was to do the equivalent thing with databases: use fancy
> types to ensure that handle can only be used inside to origination
> withDB or withCursor or whatever, and the bracketing function can
> release the resource on the way out, without worrying about it being
> used again.

I think this is an extremely good idea. I have been very frustrated with
finalizers because of their limitations (can't rely on them being
called at all), so have (reluctantly) been using the unsafe bracket
version. Making it safe via a type system trick is really the way to
go. I'll go read Oleg's paper and see if it's a workable solution.

Ben
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Db and STRef

Ben Franksen-2
On Monday 16 January 2006 13:45, Benjamin Franksen wrote:
> I think this is an extremely good idea. I have been very frustrated
> with finalizers because of their limitations (can't rely on them
> being called at all), so have (reluctantly) been using the unsafe
> bracket version. Making it safe via a type system trick is really the
> way to go. I'll go read Oleg's paper and see if it's a workable
> solution.

Oops, it's not a paper, it's code. Well then...

Ben
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe