[Haskelldb-users] Re: Opinions/Guidance wanted for starting an undergraduate project

[<adr...@ya...>]

--- Anders_Höckersten <ch...@dt...> wrote:
> Hi. It's always nice to hear from someone is
> interested in HaskellDB. 
> I'll try to answer your questions as well as I can.
> As you may or may 
> not know, I am one of the HaskellDB developers. I am
> also an 
> undergraduate student starting my 4th year this
> autumn.
Yes, so I see.  An impressive piece of project work,
both for the practical significance and as a piece of
research :).
...
> It [HaskellDB] handles 
> dynamism through a Haskell concept called monads.
> db :: (Database -> IO a) -> IO a
> db = genericConnect "sqlite"
> ["./database","ReadWriteMode"]
> addCustomer :: Customer -> IO ()
> addCustomer c = db ( \db -> insert db C.customer
> (C.iD << constant (cid c) #
> C.name << constant (cname c) #
> C.address << constant (caddr c) #
> C.price << constant (cpric c)))
> getCustomers :: IO [Customer]
> getCustomers = db ( \db ->
> do t <- query db (table C.customer)
> return (map toCustomer t))

As I understand monads, you basically have a function
which evaluates to a tuple (s,a) where s represents
some state of a system at some point in 'time' and a
is the normal 'result value.'  And then using a small
number of operators you compose several such functions
and the output state of the first operation is fed in
as the input state to the second one, and so forth.
Then the final result is simply the final (s,a) and
the messiness of the implicit intermediate states is
hidden by some nice syntacic sugaring on Haskell's
part.  The whole process being roughly akin to piping
several schemas under the Z formal specification
method.  But, it's the assignment to variables over
multiple statements that is causing me some confusion.
 For example, assuming some previously declared
customer variables, c1 & c2:

a: IO a
a=addcustomer c1

So now in addition to the value 'unit' which you just
threw away, a also contains the new system state.

b: IO a
b=addcustomer c2
Performs similarly.  Now my question was going to be,
"What happens if I direct HaskellDB to perform a query
based upon the state information held in a?  Because
databases deal with real imperative states which
become overwritten, the DBMS has no way of accessing
the database's state which it was in between the two
operations after the second addcustomer transaction
has been committed."  However my latest bit of
guesswork leads my to conclude that you are working
slightly differently from my 'bottom-up' monads
thinking and are also throwing away the 'updated'
state information and then magicing the current state
of the database into each query statement using the db
function.

This idea works, but doesn't solve the (to some extent
philosophical) problem that functional languages are
static in nature, yet our database [variable] needs to
be updated.  From what I gather HaskellDB has dodged
this problem by only ever working with a "connection
function" which (after several intermediate levels)
boils down to being a pointer to some real dynamic
database in the imperative depths of the
implementation of HSQL somewhere.  The database
doesn't exist in it's own right in Haskell at all! 
Altough another thought is that you'd be right to
object and say that databases and tables don't exist
in their own right in imperative languages either and
we'd be dealing with references via connection
functions again - except: We can wrap up such
semantics inside an object, yielding a clean (in OOP
terms) method based interface.  But variables by
reference/pointers are not a standard piece of the
functional programming paradigm, (even though SML
explicitly supports such things).  I'm not entirely
sure what my supervisor was proposing, but something
along the lines of using monads as in my examples
above, thus yielding a sort of "history of states,"
somehow prohibiting asking for anything but the
current state (the tricky part) and rely on lazy
evaluation so that the system never attempts to
compute the uncomputable past states.

> >(P.S: I haven’t actually managed to get a working
> copy
> >of HaskellDB installed yet.  GHC compiles under
> >Mandrake but fails to work.  HSQL - both Windows
> >binary and compiling from sources under Cygwin
> both fail to work. :( )
> Too bad. If you provide me with some more
> information I might be able to 
> help you with this.

GHC 6.2.1
<interactive>:1:
    Could not find interface file for `GHC.Exception'
    (use -v to see a list of the files searched for)

<interactive>:1:
    Could not find interface file for `GHC.Handle'
    (use -v to see a list of the files searched for)

<interactive>:1:
    Could not find interface file for `GHC.IO'
    (use -v to see a list of the files searched for)

<interactive>:1:
    Could not find interface file for
`System.IO.Error'
    (use -v to see a list of the files searched for)

<interactive>:1:
    Failed to load interface for `GHC.Base':
        Could not find interface file for `GHC.Base'
        (use -v to see a list of the files searched
for)
ghc-6.2.1: panic! (the `impossible' happened, GHC
version 6.2.1):
        interactiveUI:setBuffering

Please report it as a compiler bug to
gla...@ha...,
or http://sourceforge.net/projects/ghc/.


It was maked/compiled from sources under Mandrake 10,
2.4 kernel, following the install instructions given
and compiled without any errors.  (There's no
pre-compiled RPM given for Mandrake.)  Anyway having
thought that assembling the three components would be
easier under Linux, I reverted to Windows and hunted
down binaries of GHC 6.2.1, HSQL 1.4 and HaskellDB
0.8. The strange thing is that the HSQL binary only
installs on GHC 6.2.1, yet when I do install it and
run a HaskellDB example program I receive a message
saying that "package HSQL found version 6.2.0, was
expecting version 6.2.1."

Regards,

Adrian Hudnott




	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com