- Haskell-Cafe - Haskell.org

RE: Database interface
by Bayley, Alistair 14 Aug '03

14 Aug '03

> From: Thomas L. Bevan [mailto:thomas_bevan@toll.com.au] > > Ideally, we would have the following. > > 1/ A high level combinator library for relational calculus built on, > > 2/ A standard low-level Haskell API > i.e. functions like Connection -> String -> ( a -> b -> IO b) -> IO b > > 3/ Database specific bindings. > > The problem is that projections and cartesian products > generate new types, at > least in the way it was done in HaskellDB. The form the > calculus takes would > need to be substantially reworked. I don't see why the generation of new types would cause a problem. Can't we get the calculus library to generate the extraction function at the same time, so that it returns rows of the appropriate type? The generated extraction function would have to be built from standard extraction functions exposed by the low-level API. Although, would this limit the set of types you could use to just those in the low-level API? ***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************

1 0

RE: Database interface
by Tim Docker 14 Aug '03

14 Aug '03

Tom Pledger writes: > | > doquery :: (DeepSeq v) => > | > Process -> String -> IO v -> IO [v] > | > | Can you explain what the constraint does here? > > Yes. It soothes my superstitious fears about unsafeInterleaveIO. > > I imagined that: > > - doquery (like getContents) uses unsafeInterleaveIO to make the > resulting list lazy, i.e. avoid grabbing all the rows at the > outset, Actually no. I'm not sure of the correct terminology here, but my implementation was strict wrt to reading from the database - all records are read during the IO action, and not secretly later on. Whilst I can see some benefits of reading the records lazily, wouldn't this result in problems with database connection management, locks, transactions, etc. From reading the list, it sounds like equivalent issues crop up pretty regularly with getContents. If you used the fold variant, doquery :: Process -> String -> (a -> b -> IO b) -> b -> IO b where the folding function returns an IO action, then you could process rows as you go in any case, without requiring unsafeInterleaveIO. Tim

1 0

RE: Database interface
by oleg＠pobox.com 14 Aug '03

14 Aug '03

> I'll probably generalise the query function to do a fold, rathen than > always accumulate a list: > doquery :: Process -> String -> (a -> b -> IO b) -> b -> IO b If I may interject, that's precisely how a Scheme DB interface is designed. The main function is a left-fold. Not quite though: it provides for a premature termination: A major procedure: DB1:fold-left PROC INITIAL-SEED QUERY-OBJECT A QUERY-OBJECT (which in this implementation is a list of fragments that make a SQL statement, in the reverse order -- without the terminating semi-colon) is submitted to the database, using the default database connection. PROC is a procedure: SEED COL COL ... The procedure PROC takes 1+n arguments where n is the number of columns in the the table returned by the query. The procedure PROC must return two values: CONTINUE? NEW-SEED The query is executed, and the PROC is applied to each returned row in order. The first invocation of PROC receives INITIAL-SEED as its first argument. Each following invocation of PROC receives as the first argument the NEW-SEED result of the previous invocation of PROC. The CONTINUE? result of PROC is an early termination flag. If that flag is returned as #f, any further applications of PROC are skipped and DB1:fold-left finishes. The function DB1:fold-left returns NEW-SEED produced by the last invocation of PROC. If the query yielded no rows, DB1:fold-left returns the INITIAL-SEED. Thus DB1:fold-left is identical to the left fold over a sequence, modulo the early termination. There are a few minor variants of the above procedure, optimized for common particular cases: a query that is expected to return at most one row, and a query that expects to return at most one row with exactly one column. The latter query has the same interface as a lookup in a finite map. The QUERY-OBJECT is of coursed not built by hand. There is a domain-specific language (which greatly resembles the source language and makes some use of quasi-quotation) whose result is a query object. Therefore, I can write both the query and the handlers of the query result using the same syntax. The premature termination is important. Database connections and cursors are too precious resources to leave them for the garbage collector to finalize. More discussion and pointers can be found at http://srfi.schemers.org/srfi-44/mail-archive/msg00023.html The interface has been used in an industrial application.

1 0

haskell newbie seeking for advice
by Jose A.Ortega Ruiz 14 Aug '03

14 Aug '03

hi all, as stated in the subject, i'm a newcomer to haskell programming: i've read some tutorials and (portions of) a couple of books and am really fascinated with the language. but my haskell coding experience is limited to toy programs and short exercises. so i decided to try my hand at a small project to really learn haskell and the functional programming mindset[1], and i would appreciate to hear your opinions and comments on some issues before i start coding: - build toolchain. i'm used to the autoconfig/automake/make tools for C/C++ projects, and to ant for Java stuff. what do haskellers use? my initial thought was using a plain Makefile with ghc, but there is also hmake and maybe other tools i am missing. what would you use? [2] - graphics toolkit. one of my programs will be a GUI. there seems to be a lot of choice here: gtk2hs looks nice (as used in hircules) and fudgets seems to have a pretty interesting and well-documented architecture (which covers also client/server programming: i'll be using a client/server architecture too) but its widgets are uglier and look alien in current linux desktops. i'd like to have a fudgets-gtk framework of sorts :) and then, there is htoolkit, Object I/O and whatnot... any recommendations? - TCP/IP stuff. i will have a client/server architecture with TCP/IP as the transport protocol. other than fudgets, i'm not aware of any haskell framework for IPC: am i missing something? - XML. i'll be handling XML documents, and HaXml seems to me an excellent candidate to cover this area, but, of course, i'm very interested in hearing of alternatives... thanks a lot for your help! cheers, jao Footnotes: [1] if that matters, the project will consist on a set of utilities for handling a document metadata database, based upon the OMF standard. [2] my project will consist of several executables, sharing a set of common libraries and, therefore, i plan to use (if possible) a non-flat directory layout. -- Come to think of it, there are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare. - Blair Houghton.

4 3

RE: Database interface
by Tim Docker 14 Aug '03

14 Aug '03

Tom Pledger writes: > This is a pretty good way to stop those nasty vague SQL row types at > the Haskell border and turn them into something respectable. Perhaps > it would even be worth constraining the extracted type to be in > DeepSeq > > doquery :: (DeepSeq v) => > Process -> String -> IO v -> IO [v] Can you explain what the constraint does here? Although I haven't touched the db interface in the meantime, when/if I do, I'll probably generalise the query function to do a fold, rathen than always accumulate a list: doquery :: Process -> String -> (a -> b -> IO b) -> b -> IO b Tim

2 1

Fwd: Re: Yet Another Monad Tutorial
by blaat blaat 13 Aug '03

13 Aug '03

>From: Derek Elkins <ddarius(a)hotpop.com> >"blaat blaat" <l4t3r(a)hotmail.com> wrote: [...] > > However, given that observation, the fact that IO is a monad I find to > > be a _rather arbitrary design decision_; why not define a small term > > language which may be passed to the OS? > >That would be confusing to use or restrictive (unless done exceedingly >well perhaps), it would be awkward to define, and it would pretty much >require arbitrary design decisions (what should be included in this >language? what are it's semantics? etc). > > Why not have (some limited) > > introspection on programs which we build? > >It would be round-about in both implementation and use to do this. >Nevertheless, you can easily view the IO monad as an imperative language >-embedded- in Haskell. Even when writing mostly imperative code >Haskell gives you much more flexibility and protection than many >imperative languages, especially the more popular ones. > >[...] > > > Are we missing out on usefull stuff? > >No, but if we were, it'd be trivial to test/get it with an appropriate >top-level runTheProgram IO computation definable in Haskell today. Trivial to test I fully agree with; however, to the missing out on usefull stuff I am not convinced. Please allow me to continue my trolling. To use the IO monad for impure calculations is, of course, a design decision. It is arbitrary to the point that I have the freedom not to agree with it; but hey, even I know the thing works ;-). The key point to my email was that doing impure IO possibly has little to do with a monadic style of programming but with the fact that we can functionally construct a description of an impure program which is evaluated _only_ when delivered as a sole result of a Haskell computation. I find that somewhat odd; but not to the point I cannot live with it ;-) About the indirectness issue. The benefit of choosing a monad is clear - the evaluation/rewrite of an action corresponds directly with an impure subroutine call. Moreover, the action can be discarded and, as you pointed out, the description of these impure subroutine calls are trivially embedded directly into Haskell - giving typesafety as a reward. It is both effective and efficient. Great.... Hail to the monad! Hmmm, uhm, but let's think further... What did we lose? Well, introspection comes to mind. A monad is strange in the sense that, actually, there does not seem to be any reason to compute its value since we cannot possibly get anything out of it. In case of IO, only the haskell interpreter can. And, introspection is a nice thing to have, especially for compiler writers. Although I think the benefits in Haskell would be limited, an application might be that I could write my own promotion functions on my own programs. Think of the following though experiment. What if I would have a function "unparse:IO a->String" which gives the textual representation of the specification of the object of type IO a? Clearly, IO is not a monad anymore. Moreover, I don't think it would break the purity of Haskell. And surely, in case of the IO monad, we can think of better manners to break a program down. Hmm, I am rambling. The point is, I think there is no reason to discard all alternatives to monads; I believe that central in the IO-issue is not the fact that we are using monads for IO - but that we can purely create impure programs which do the IO for us ;-), and that those do not have to be of the monadic kind (with all respect to the baffling ingenuity of the invention). Cheers, l4t3r _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 2

Re: Yet Another Monad Tutorial
by Derek Elkins 13 Aug '03

13 Aug '03

On Wed, 13 Aug 2003 13:26:34 +0200 "blaat blaat" <l4t3r(a)hotmail.com> wrote: I have a long reply, perhaps I'll post it later. Here's a more pragmatic short one. > What did we lose? Well, introspection comes to mind. A monad is > strange in the sense that, actually, there does not seem to be any > reason to compute its value since we cannot possibly get anything out > of it. In case of IO, only the haskell interpreter can. And, > introspection is a nice thing to have, especially for compiler > writers. Although I think the benefits in Haskell would be limited, an > application might be that I could write my own promotion functions on > my own programs. Lot's of issues with this paragraph, but here are the questions. What do you mean by "promotion function"? How would you write it in your hypothetical Haskell? How is it related to IO? How do monads and/or the IO monad in particular cause problems? Why couldn't the same be done using monads or why would it be significantly harder if it can be done? > Think of the following though experiment. What if I would have a > function "unparse:IO a->String" which gives the textual representation > of the specification of the object of type IO a? Clearly, IO is not a > monad anymore. Moreover, I don't think it would break the purity of > Haskell. And surely, in case of the IO monad, we can think of better > manners to break a program down. Keith has already pointed out the flagrant error here; which I also point out in my long reply. But again, the questions... What is unparse supposed to return? What does it have to do with IO in particular, i.e. why do I want to unparse IO computations especially? Why can't it be done with (or over) the current IO monad? What other ways do you want to breakdown a program, still resulting in understandable behavior, but can't because of the IO monad? > Hmm, I am rambling. The point is, I think there is no reason to > discard all alternatives to monads; > I believe that central in the > IO-issue is not the fact that we are using monads for IO - but that we > can purely create impure programs which do the IO for us ;-), and that > those do not have to be of the monadic kind. I have comments for these too, but I'll keep this short. Basically, I don't really see how what you want has all that much to do with IO in general, and I don't see monads get in the way.

1 0

[String]->[[Bool]]
by Tn X-10n 13 Aug '03

13 Aug '03

2 1

[String]->[[Bool]] 2
by Tn X-10n 13 Aug '03

13 Aug '03

2 1

Yet Another Monad Tutorial
by blaat blaat 13 Aug '03

13 Aug '03

Hmmm, I personally always thought of the IO monad as being a synonym for "Program" (or, for functions wich return an IO a, "a subroutine with side-effects which returns a value of type a"). We can build mini programs (like putStr), and compose them in a sequential manner (including something alike assignment). I personally use the following analogy. Someone, somewhere, sometime must have thought, "Great, if I cannot do imperative programming directly, I can damned well create imperative programs and have _them_ evaluated, grumbl!" And with that thought, he solved numerous problems ;-) Can we really make cheese out of it? (Dutch saying) For what is the interpretation of an object of type IO a? Well, it is a bit of a hack atop of Haskell, isn't it? If we return a complex type with an IO a object in it, the object cannot be evaluated, but if we return a IO object solely (program), the program get evaluated (passed to the (Haskell)-OS). However, given that observation, the fact that IO is a monad I find to be a _rather arbitrary design decision_; why not define a small term language which may be passed to the OS? Why not have (some limited) introspection on programs which we build? Purity will never be broken since the only way to get a "program" evaluated is to pass it to the Haskell-OS. Are we missing out on usefull stuff? Hehe... God, we might as well just generate impure graph rewrite rules,.... or plain C for that matter ;-). Cheers, l4t3r ps: Mind you, nothing wrong with that IO monad. It works, why break it. ;-) _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2