- Haskell-Cafe - Haskell.org

Haskell book recommendation?
by bjkwak 16 Jul '03

16 Jul '03

Hi! Searching for a new programming language for my work, I got interested in functional languages. After several weeks of googling and searching, I decided to learn Haskell. I have downloaded and read some tutorials from the Haskell home page, but most of them are incomplete and I decided to buy a book or two. I have found a list of books on Haskell in the Haskell home page, but I cannot decide from the information given in the page. Could any body give me some advice? I have some experience in C, but never programmed in functional language before. I have read about 1/4 of the book "ML for the working programmer" by L.C. Paulson. Thanks! Byung-Jae

3 4

re: infinite types
by blaat blaat 16 Jul '03

16 Jul '03

Sorry if this mail starts a new thread. I am not subscribed to haskell-cafe and am new to hotmail. Uhm, as far as the example goes. I was trying to define a small (shallow encoding of) a reactive systems language. Because I wanted to try something else than monads I defined the following recursive type for a reactive system. type R m = m -> Maybe (R m, [m]) Supposedly a reactive system is a system which may not take a message (the Maybe), or do take it and respond with an updated version of itself, and a sequence of outgoing messages. For example, a copying machine might be defined as: id:R m id m = Just (id, [m]) A version for a ?Meally? machine embedding (always take an incoming message, and respond with one outgoing message) could be written as type Meally i o = i -> (Meally i o, o) where id is defined as id::Meally a a id m = (id, m) I like the formalization because (a) it is concise, (b) structural composition operators can be defined trivially, (c) hides the state of a machine, (d) might possibly, in the long run, somewhere, even work out equally well as a monadic approach. Does it make sense? Are there any known references to this approach? Cheers, l4t3r PS: Actually, I just realized this might be the co-algebraic approach, so I guess I am asking for a haskell which allows co-algebraic types. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

infinite types
by blaat blaat 16 Jul '03

16 Jul '03

Hi al! In my holliday I like to hobby a bit with haskell. For a small formalization I wanted to try out a specification which uses infinite types. Does a (extended) haskel compiler exist which allows infinite types? Chees, l4t3r _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

RE: functional "updatable" graph
by Hal Daume 15 Jul '03

15 Jul '03

>> I think that the >> difficulties you are >> facing are from the fact that you are trying to >> express a purely >> functional "updatable" graph. > > Should I understand from this, that this is a > difficult problem and that there exist no easy way to > do this at the moment? Well, I think he was being a bit ironic. You can either have a functional graph or an updatable graph, but not both. It sounds like either would do and given that later in this message you discuss that you don't like imperativeness, then a functional graph (ala the Functional Graph Library -- FGL) would suit you perfectly. > About the graphs:Well, I never had graphs at school > yet(first year student)... Although it is somewhere in > my textbooks... They're very simple. You have a collection of nodes, N, and a collection of edges between elements of N. Nodes and edges can have labels. So for instance you could have Teachers and Classes as the nodes and the edges could be between the teacher and the class(es) which go together. > To solve my problem... I need an mutable array, but in > Haskell my program will then be unbelievable > imperative. No, you just need a graph :). > I have been following the discussion about the graph > and so, but the arrow classes and so on, are like > something too sophisticated for me at this moment I > think, although I have some idea of how they work, I > really don't know when to apply them. I just found > out, how Monads work, so... THe discussion about arrows is a complete divergence. You don't need anything about them. > But I certainly believe that my problem must be fixed > before it's easy to program in Haskell. Theorem: this problem is already fixed. Proof: it is easy to program in Haskell. QED. :) - Hal

2 1

Simple monads
by Mark Carroll 15 Jul '03

15 Jul '03

Not really seeing why Unique is in the IO monad, not deeply understanding the use of Haskell extensions in the State source, and wanting to try to learn a bit more about monads, I thought I'd try to write my own monad for the first time: something for producing a series of unique labels. This is how it turned out: ========================================================================== module Label (Label, Labeller, newLabel) where import Monad newtype Label = Label Int deriving (Eq, Ord) newtype Labeller a = Labeller (Int -> (Int, a)) instance Monad Labeller where return r = Labeller (\n -> (n, r)) (Labeller g) >>= y = let f m = let (r, n) = g m Labeller h = y n in h r in Labeller f newLabel :: Labeller Label newLabel = Labeller (\n -> (n + 1, Label n)) runLabeller :: Labeller a -> a runLabeller (Labeller l) = snd (l minBound) labelTest :: Labeller [Int] labelTest = do Label a <- newLabel Label b <- newLabel Label c <- newLabel Label d <- newLabel return [a,b,c,d] main = print (runLabeller labelTest) ========================================================================== I was thinking that maybe, (a) People could point out to me where I'm still confused, as revealed by my code. Is it needlessly complicated? (b) My code may be instructive to someone else. -- Mark

12 24

Handling large ini files.
by Thaddeus L. Olczyk 14 Jul '03

14 Jul '03

A while ago I looked at Haskell. I got stuck on a problem which basically caused me to stop using Haskell. Realising that I never asked anyone else how they would approach the deal, I decided to ask before I put the final chapter on Haskell. I have a program that requires a lot of customisation. As a result there is an initialization file with many entries ( typically 30-80 entries ). Some of these entries need to be accessed quite often, so that opening the file and reading in on demand is not really an option. So the basic question is how do I handle access to these parameters? PS: I've thought of Hugh's approach to global variables, but even with compound data structures it really isn't practical for such a large number. Not even when creating compound structures to hold the data. Worse you wind up with data structures which are not coherent having only the fact that each is a customisation in common. Thaddeus L. Olczyk ----------------------- Think twice, code once.

4 3

RE: Designing a Haskell database interface
by Tim Docker 14 Jul '03

14 Jul '03

I wrote an experimental wrapper around the sybase db client libraries. This was my first attempt at using the ffi, and I was impressed with the fact that I got enough working purely using haskell. My simplistic approach was to embed everything in the IO monad, wrapping each sybase call trivially, and then building slightly higher level functions on top of each. Of course, the fun with handling queries is that you want to get values of types defined by the query string (ie unknown at compile time) from the database and into the typed haskell world. In my approach, the top level interface looked like: open :: String -> String -> String -> IO Process -- open a connection to the database returning an abstract -- process object doquery :: Process -> String -> IO v -> IO [v] -- Takes: a db process; the SQL query string; and -- a (no parameter) IO action that, when executed -- during a query returns a value of type v derived -- from the "current" row -- -- Returns the list of values of type v derived from -- each row. stringv :: Process -> CInt -> IO String doublev :: Process -> CInt -> IO Double intv :: Process -> CInt -> IO Int datetimev :: Process -> CInt -> IO DateTime -- Returns the string/double/int/datetime value of the specified -- column in the "current" row You could then write queries something like this: dbp <- DB.open "SERVER" "user" "password" rows <- DB.doquery dbp queryText $ do name <- DB.stringv dbp 1 v1 <- DB.doublev dbp 2 v2 <- DB.doublev dbp 3 return (label,v1,v2) At which point rows would have type [(String,Double,Double)]. This did the job, but I'd be interested in better ways of doing it! Tim > -----Original Message----- > From: Bayley, Alistair [mailto:Alistair_Bayley@ldn.invesco.com] > Sent: Monday, July 14, 2003 4:25 PM > To: haskell-cafe(a)haskell.org > Subject: Designing a Haskell database interface > > > I'm making slow progress on an Oracle OCI binding. I've got the noddy > session setup and database connection stuff working, so now > I'm looking at > how results should be returned from SQL queries. In Haskell, > there doesn't > seem to be any consistent way of returning results from SQL > queries, unlike > (say) Java's JDBC interface. It may be a bit early to propose > a standard SQL > dbms interface design, but... does anyone have any idea(s) > about how one > ought to look? > > Here's a simple survey of the sql dbms interfaces I've come > across so far (I > found HaskellDB the most complex, and difficult to understand). My > assumptions about how these various libraries work might be > quite wrong: > > > HaskellDB: > dbQuery returns IO [row r], where > - dbQuery is implemented by adoQuery (this library uses Odbc): > adoQuery :: IConnection () -> PrimQuery -> Rel r -> IO > [AdoRow r] > - "AdoRow a" is an instance of class Row > - "class Row row a" declares one function: rowSelect > rowSelect :: Attr r a -> row r -> a > - type AdoRow implements rowSelect with adoRowSelect: > adoRowSelect :: Variant a => Attr r a -> AdoRow r -> a > - Attr has one constructor: Attr Attribute, and Attribute is just a > synonym for String. > So (I think) the return types are determined by the types > of the phantom > types in "Attr r a" and "AdoRow r". And this is where my head > explodes... > > > LibPQ: > fetchAllRows returns tuple pair of the connection and row : (DBI a, > [[String]]) > - so, a row is a list of list of Strings. > > > HaSql: > haSQLObtainQueryResults returns SQL [a], where > - SQL is some custom IO+State Monad > - the type of a is the return type of a function you pass to > haSQLObtainQueryResults to (I think) convert an Odbc pointer > into a Haskell > type. > > > MySql-hs: > mysqlQuery returns a tuple of (Integral, [[Maybe String]], > [MysqlField]), > where > - the first element (Integral type) is the number of rows > - the second element is a list of list of Strings - the result set. > - the third element is metadata. MysqlField is a record > describing a > database column. > > > The most sophisticated implementation wrt type information seems to be > HaskellDB. My initial goal was to use this library and > provide an Oracle > database driver for it, but the HaskellDB seems to be quite > dependent on > Trex, which AFAICT is a Hugs library. > > I was thinking of splitting it into two parts: a library that > submits SQL > queries and returns the results, and a library that > constructs queries with > the relational calculus and generates SQL from them. The > relational calculus > bit was what I was interested in, but for now I want to work > on getting data > out of my Oracle database. > > > Also... > > I was wondering how you might go about mapping arbitrary dbms > types to a > Haskell result set. > > In an ideal world, you can store any values you like in a "relational" > database. However, most SQL dbms products give you just > numbers, text, and > dates. Some dbms's (PostgreSql and Oracle) allow > users/programmers to create > new types and let the dbms treat them in the same manner as > the built-in > ones i.e. with equality and ordering predicates, and > indexing. The built-in > support for the three basic types (numbers, text, dates) is > reflected in the > JDBC API; it has methods like: getByte, getShort, getFloat, getDouble, > getBigDecimal, getInt, getString, getDate, getTime, > getBoolean, while other > types are handled by methods like getBinaryStream and getObject. > > So how would you convert a (say) PostgreSql Point or Box > value to a Haskell > type? Would the approach taken by HaSql be the best (the user > provides a > function that converts binary data into a Haskell value)? > > > ***************************************************************** > 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. > ***************************************************************** > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Designing a Haskell database interface
by Bayley, Alistair 14 Jul '03

14 Jul '03

I'm making slow progress on an Oracle OCI binding. I've got the noddy session setup and database connection stuff working, so now I'm looking at how results should be returned from SQL queries. In Haskell, there doesn't seem to be any consistent way of returning results from SQL queries, unlike (say) Java's JDBC interface. It may be a bit early to propose a standard SQL dbms interface design, but... does anyone have any idea(s) about how one ought to look? Here's a simple survey of the sql dbms interfaces I've come across so far (I found HaskellDB the most complex, and difficult to understand). My assumptions about how these various libraries work might be quite wrong: HaskellDB: dbQuery returns IO [row r], where - dbQuery is implemented by adoQuery (this library uses Odbc): adoQuery :: IConnection () -> PrimQuery -> Rel r -> IO [AdoRow r] - "AdoRow a" is an instance of class Row - "class Row row a" declares one function: rowSelect rowSelect :: Attr r a -> row r -> a - type AdoRow implements rowSelect with adoRowSelect: adoRowSelect :: Variant a => Attr r a -> AdoRow r -> a - Attr has one constructor: Attr Attribute, and Attribute is just a synonym for String. So (I think) the return types are determined by the types of the phantom types in "Attr r a" and "AdoRow r". And this is where my head explodes... LibPQ: fetchAllRows returns tuple pair of the connection and row : (DBI a, [[String]]) - so, a row is a list of list of Strings. HaSql: haSQLObtainQueryResults returns SQL [a], where - SQL is some custom IO+State Monad - the type of a is the return type of a function you pass to haSQLObtainQueryResults to (I think) convert an Odbc pointer into a Haskell type. MySql-hs: mysqlQuery returns a tuple of (Integral, [[Maybe String]], [MysqlField]), where - the first element (Integral type) is the number of rows - the second element is a list of list of Strings - the result set. - the third element is metadata. MysqlField is a record describing a database column. The most sophisticated implementation wrt type information seems to be HaskellDB. My initial goal was to use this library and provide an Oracle database driver for it, but the HaskellDB seems to be quite dependent on Trex, which AFAICT is a Hugs library. I was thinking of splitting it into two parts: a library that submits SQL queries and returns the results, and a library that constructs queries with the relational calculus and generates SQL from them. The relational calculus bit was what I was interested in, but for now I want to work on getting data out of my Oracle database. Also... I was wondering how you might go about mapping arbitrary dbms types to a Haskell result set. In an ideal world, you can store any values you like in a "relational" database. However, most SQL dbms products give you just numbers, text, and dates. Some dbms's (PostgreSql and Oracle) allow users/programmers to create new types and let the dbms treat them in the same manner as the built-in ones i.e. with equality and ordering predicates, and indexing. The built-in support for the three basic types (numbers, text, dates) is reflected in the JDBC API; it has methods like: getByte, getShort, getFloat, getDouble, getBigDecimal, getInt, getString, getDate, getTime, getBoolean, while other types are handled by methods like getBinaryStream and getObject. So how would you convert a (say) PostgreSql Point or Box value to a Haskell type? Would the approach taken by HaSql be the best (the user provides a function that converts binary data into a Haskell value)? ***************************************************************** 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

Multiple "pointers" to "objects"
by Ron de Bruijn 14 Jul '03

14 Jul '03

Hi there, I was almost certain that Haskell was a great language until I wanted to make a real usefull program and got the following problem. I have data Lesson = Lesson Teacher SomeOtherProperties deriving Show data Subject = Subject Name [Teacher] SomeOtherProperties deriving Show data Teacher = Teacher TimeTable SomeOtherProperties What I want is that when I put some lesson in my timetable, the resources needed for that lesson are used up, so for example the timetable of a teacher will fill with each lesson that it gives. The problem is that when I "model" it this way, the state of the teachers that can give a certain subject will not change (suppose I have some function that fills one timeslot of the timetable of a teacher). It makes it even harder, because of the fact that one teacher can teach multiple subjects. In an OO-language I would simply let each element of the list of TeacherObjects of Subjects point to some TeacherObject, so it remembers it state, but that's anti-Haskell. It's ofcourse possible to put a list of Subjects that a Teacher teaches in the data declaration of the teacher. But then there is no way of saying efficiently (O(1) Just a pointer or index):"Give me a list of all teachers that give Physics", and that's just what I need. I could use a hashtable which includes the teachersobjects as values and the subjects as keys, but that isn't a very beautiful solution. This would give me(building of Hashtable O(n) and getting all teachers of some subject O(1)), so it would do. I am almost sure there exist some nice way of doing this, because otherwise Haskell would be completely useless IMHO, but I don't know it. Do you have any idea? Greets Ron __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

3 2

Re: functional "updatable" graph
by Ron de Bruijn 13 Jul '03

13 Jul '03

Are you sure that your data structure shouldn't be expressed by a graph? In that case, there is a very recent thread (last post today) on functional graph algorithms. I think that the difficulties you are facing are from the fact that you are trying to express a purely functional "updatable" graph. Should I understand from this, that this is a difficult problem and that there exist no easy way to do this at the moment? About the graphs:Well, I never had graphs at school yet(first year student)... Although it is somewhere in my textbooks... To solve my problem... I need an mutable array, but in Haskell my program will then be unbelievable imperative. I have been following the discussion about the graph and so, but the arrow classes and so on, are like something too sophisticated for me at this moment I think, although I have some idea of how they work, I really don't know when to apply them. I just found out, how Monads work, so... But I certainly believe that my problem must be fixed before it's easy to program in Haskell. Greets Ron __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

1 0