- Haskell-Cafe - Haskell.org

Re: Yet Another Monad Tutorial
by Bernard James POPE 15 Aug '03

15 Aug '03

Hi all, I've been following this discussion with some interest. Last time I looked, hugs, ghc and nhc98 all implemented I/O differently. No doubt there are even more alternatives in other Haskell implementations (real or imaginary). In itself this is probably not too surprising. They are, afterall, different systems with different goals etc. However, I have often wondered what it is that constitutes a correct implementation of the I/O system in Haskell. I might be wrong, but I don't think the Haskell Report helps much in this regard. The only source of semantics for Haskell's I/O that I know of is "Tackling the Awkward Squad" by Simon Peyton Jones. If there are others I'd love to have them pointed out. However, this paper deals with many extensions that are not in Haskell 98. I'm not sure if there is enough in it to decide if a given implementation is correct (I use the word "correct" loosely). I would really love to see a discussion of the design space for I/O. Including what the current compilers use, what other options there might be, and even what other languages use (like Clean's and Mercury's uniqueness systems). If I were to build a Haskell compiler tomorrow this is one thing I would like to know - what do I have to do to ensure that my implementation of I/O is correct and what design options do I have? No doubt the I/O systems of current compilers have grown with those systems, but from the perspective of someone who is outside of the implementations it would be interesting to know why things are done the way they are, and what other options were considered, rejected, etc. For example, the state-of-the-world threading approach might be chosen because it is economical with respect to implementation cost in an existing compiler (such as GHC). But if we were to write a compiler from scratch would/should we follow the same route? Also, the "Keep the monad right through" method that Simon mentions in the "awkward squad" paper is interesting, but I wonder if that is too hard to implement in Haskell due to extensive overloading of the monad operators. I'll stop rambling now. Cheers, Bernie.

1 0

RE: IO Bool -> Bool
by Kevin S. Millikin 15 Aug '03

15 Aug '03

On Wednesday, August 13, 2003 11:20 PM, Tn X-10n [SMTP:kawairashii@hotmail.com] wrote: > is it possible to convert IO Bool to Bool? Sure. Which Bool do you want? True? > toTrue :: IO Bool -> Bool > toTrue x = True Or False? > toFalse :: IO Bool -> Bool > toFalse x = False Maybe that's not what you had in mind.

4 3

RE: Database interface
by Tim Docker 14 Aug '03

14 Aug '03

oleg(a)pobox.com wrote: > 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 Premature termination sounds like a useful property. I can see two ways this could be done: keep the previous signature, and use an exception to exit early, or add a boolean return value like the scheme version: doquery :: Process -> String -> (a -> b -> IO (b,Bool)) -> b -> IO b Any opinions on which alternative wouuld be preferable? Tim

2 1

Re: Yet Another Monad Tutorial
by Jeff Newbern 14 Aug '03

14 Aug '03

Alistair, Thanks for your message regarding the debate about monads and purity. What do you think about these additions as a discussion of the issue? Does this address everything you think is needed? Is there a clearer way to explain it? Thanks, Jeff In the section "No Way Out": ---------- The IO monad is a familiar example of a one-way monad in Haskell. Because you can't escape from the IO monad, it is impossible to write a function that does a computation in the IO monad but returns a non-monadic value. Not only are functions of the type IO a -> a impossible to create, but any function whose result type does not contain the IO type constructor is guaranteed not to use the IO monad. Other monads, such as List and Maybe, do allow values out of the monad. So it is possible to write non-monadic functions that internally do computations in those monads. The one-way nature of the IO monad also has consequences when combining monads, a topic that is discussed in part III. ---------- and a little farther down: ---------- Some people argue that using monads to introduce non-pure features into Haskell disqualifies it from claiming to be a pure functional language. This subtle question — not particularly relevant to the practical programmer — is revisited in the context of the I/O monad later in the tutorial. ---------- Later, in the section on the I/O monad: ---------- In Haskell, the top-level main function must have type IO (), so that programs are typically structured at the top level as an imperative-style sequence of I/O actions and calls to functional-style code. Revisiting the debate about the purity of Haskell (in a functional sense), it is important to note that the IO monad only simulates imperative-style I/O. The functions exported from the IO module do not perform I/O themselves. They return I/O actions, which describe an I/O operation to be performed. The I/O actions are combined within the IO monad (in a purely functional manner) to create more complex I/O actions, resulting in the final I/O action that is the main value of the program. The result of the Haskell compiler is an executable function incorporating the main I/O action. Executing the program "applies" this ultimate I/O action to the outside world to produce a new state of the world. This occurs only once per execution of the program, and since the state of the world changes for each execution, the issue of purity is neatly side-stepped. ---------- -- Jeff Newbern <jnewbern(a)nomaware.com> Nomaware, Inc.

8 8

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

14 Aug '03

> -----Original Message----- > From: Thomas L. Bevan [mailto:thomas_bevan@toll.com.au] > > This type of interface is fine as far as it goes, but there is only > ever a loose coupling between the database and application. > > The HaskellDB work implemented a relational calculus that ensured > that all queries were checked at compile time for validity against > a particular database. HaskellDB doesn't actually type check against the database; it checks against types defined in a module, which is generated from the database. If you change the database, then you need to regenerate the module. I prefer the approach of passing an extraction function/IO action to the interface. This is the approach taken by HaSql, HaskellDB (I think, although it's so indirect I find it hard to follow), and Tim Docker's Sybase library, and it's the design I intend to use for my Oracle library (when I get around to it). I still want to use HaskellDB (or at least the relational calculus part of it), so I was thinking of splitting it into two pieces: a library that submits SQL queries and returns the results (database interface), and a library that constructs queries with the relational calculus and generates SQL from them. Obviously the database interface must be written for each DBMS product, while the relational calculus library ought to be independent of DBMS (although it might be wise to have SQL compatibility flags for the SQL it generates. For example: Oracle 8 (what I'm using now) only supports SQL-92). ***************************************************************** 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. *****************************************************************

2 1

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 13 Aug '03

13 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