Re: [Haskell] Re: Haskell DB bindings (was Re: ANN: HDBC (Haskell Database Connectivity)

2006-01-17 Thread Keean Schupke

John  wrote:


On 2006-01-14, Keean Schupke [EMAIL PROTECTED] wrote:
 

Erm, has nobody replied to this yet? I want a robust interface, that 
uses bracket notation all the way down, so that any error is caught and 
resources are freed appropriately without the use of finalizers (which 
may not get run and lead to resource starvation - they are not reliable 
   



To be sure, your only failure situation in this case is if you're
dealing with many connections *and* creating/destroying them frequently.

Hopefully you wouldn't be.
 

You could be using connection pooling in the database driver or ODBC 
layer... Here the minimal
overhead of opening/closing allows you to use a bracket within each 
connection, rather than around
the whole server. Besides which the goal is not just to be safe in 
practice, but to be theoretically safe in all
circumstances. If you allow the programmer to shoot themselves in the 
foot, then they often will (for example
memory management and buffer overflows)... Its no good to partly remove 
responsibility, as that makes bugs
more likely not less likely (If the programmer has to deal with an 
opaque system with flaws, unless the programmer
is highly aware of those flaws they will take no account of them in 
their coding). The only way you can give the
programmer a genuine black box to play with, is if it is theoretically 
safe, then the programmer can (ab)use it

how they wish without accidentally breaking the conditions of usage.

Regards,
   Keean.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


Re: [Haskell] Re: Haskell DB bindings (was Re: ANN: HDBC (Haskell Database Connectivity)

2006-01-17 Thread Benjamin Franksen
On Tuesday 17 January 2006 16:08, Keean Schupke wrote:
 John  wrote:
 On 2006-01-14, Keean Schupke [EMAIL PROTECTED] wrote:
 Erm, has nobody replied to this yet? I want a robust interface,
  that uses bracket notation all the way down, so that any error is
  caught and resources are freed appropriately without the use of
  finalizers (which may not get run and lead to resource starvation
  - they are not reliable
 
 To be sure, your only failure situation in this case is if you're
 dealing with many connections *and* creating/destroying them
  frequently.
 
 Hopefully you wouldn't be.

 You could be using connection pooling in the database driver or ODBC
 layer... Here the minimal
 overhead of opening/closing allows you to use a bracket within each
 connection, rather than around
 the whole server. Besides which the goal is not just to be safe in
 practice, but to be theoretically safe in all
 circumstances. If you allow the programmer to shoot themselves in the
 foot, then they often will (for example
 memory management and buffer overflows)... Its no good to partly
 remove responsibility, as that makes bugs
 more likely not less likely (If the programmer has to deal with an
 opaque system with flaws, unless the programmer
 is highly aware of those flaws they will take no account of them in
 their coding). The only way you can give the
 programmer a genuine black box to play with, is if it is
 theoretically safe, then the programmer can (ab)use it
 how they wish without accidentally breaking the conditions of usage.

I agree most strongly. Furthermore, as a /user/ of a library, what I 
want is simple semantics and guarantees are always simpler than side 
conditions, take care when doing this or that, etc.. I just don't 
want to have to care about such stuff. Also, to make things easier one 
often choses bad programming style (defensive programming) in order 
to avoid the complex reasoning necessary to ensure that the program 
behaves well. For instance, it is tempting to encapsulate the whole 
program into the 'withDB' bracket, instead of only the part that 
actually uses the DB connection, just to be on the safe side. If the 
type system catches this kind of errors, one is encouraged to restrict 
the scope of the DB connection (or whatever), resulting in earlier 
freeing of resources and better modularity.

Ben
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell


[Haskell] Re: Haskell DB bindings (was Re: ANN: HDBC (Haskell Database Connectivity)

2006-01-15 Thread John Goerzen
On 2006-01-14, Keean Schupke [EMAIL PROTECTED] wrote:
 Erm, has nobody replied to this yet? I want a robust interface, that 
 uses bracket notation all the way down, so that any error is caught and 
 resources are freed appropriately without the use of finalizers (which 
 may not get run and lead to resource starvation - they are not reliable 

To be sure, your only failure situation in this case is if you're
dealing with many connections *and* creating/destroying them frequently.

Hopefully you wouldn't be.

 if dealing with many connections, unless you start forcing garbage 
 collections). I want a simple interface (as few functions as possible to 
 do the job) and robust exception handling.

HDBC will let you manually close (and free) database objects.  If you
don't manually do that, they will be automatically closed/freed at
garbage collection time.  It uses a small C wrapper to make this happen
correctly.

It doesn't have built-in support for bracketing things all the way down,
but functions to do that are already in the testsuite.  It would be
trivial to add them to HDBC proper, since there is robust exception
handling all through.

The HDBC API is at:

http://darcs.complete.org/hdbc/doc/Database-HDBC.html

I didn't honestly follow the STRef discussion, or how something so
I/O-based could work there.

-- John

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell