- Haskell-Cafe - Haskell.org

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

Re: Representing cyclic data structures efficiently in Haskell
by Sarah Thompson 12 Jul '03

12 Jul '03

>>From reading your message, it seems you want a graph library of sorts. > The important bit is 'of sorts', unfortunately! Most graph libraries I've seen to date (although I must admit that they have been written in C and C++, including one I perpetrated personally) don't really work that well for circuits because, for anything other than trivially simple components, the connections between nodes need to be labelled. A component representing something simple like (say) an 'and' gate would be easy enough to represent as a node of an ordinary directed graph. In such a case, an incoming arrow would always be an input of the gate, and an outgoing arrow would always be the output. I need to be able to represent more complex components, up to and including the complexity of things like CPUs, where you might have lots and lots of inputs and outputs with substantially different meanings. In the case of a CPU, it would never be acceptable to (for example) swap a chip select output for an address or data line. This makes me think that an off-the-shelf graph library won't quite be what I'm after, so I will almost certainly need to write the code. What I'm more interested in at the moment is a view on the best kinds of approach that might be appropriate. I'd considered something like embedding the type in the IO monad, with links between components implemented as IORefs, but I'd really prefer something cleaner (pure functional). If the code ends up horribly complicated in order to get decent performance, I might as well fold and use C++ instead. I'm currently wondering about going for an adjacency list approach (as used by most graph libraries), with the tuples in the adjacency list extended to include input/output labels, resulting in a 4-ary tuple rather than the usual 2-ary. But, I don't want to be stuck with representing this as a list -- I really need log N lookups or performance will stink horribly as circuits get big. Maybe a pair of finite maps, allowing the edges to be traversed in either direction? >If FGL seems like overkill to you, I have my own little mini graph >library which basically looks like: > > - An ADT, Node: newtype Node = Node Int deriving ... > - The 'Graph n e' data structure, containing: > - a FiniteMap from n -> Node > - an (growable?) array of type IOArray (Node,Node) e > >the array represents the edges in the top half (i do some index fiddling >to get this efficient) and the finitemap represents the node labellings. >It's a pretty stupid interface and works a lot better when the graphs >are fixed size (that way you don't need to grow the array). But it >works. > > The finite map from n to Node seems like a good idea. Does representing the adjacency list as a flat array cause any problems? Sarah -- ---------------------------------------------- / __ + / Sarah Thompson **** / / (_ _ _ _ |_ / * / / __)(_|| (_|| ) / sarah(a)telergy.com * / / + / http://findatlantis.com/ / ---------------------------------------------- -- ---------------------------------------------- / __ + / Sarah Thompson **** / / (_ _ _ _ |_ / * / / __)(_|| (_|| ) / sarah(a)telergy.com * / / + / http://findatlantis.com/ / ----------------------------------------------

4 3

accessing Haskell-Cafe from oe
by Jeff Aimt 12 Jul '03

12 Jul '03

Hello, I discovered recently (thanks google) that Haskell Cafe was also named "fa.haskell", but can't find a news server which would let me access it like any other newsgroup. If someone accesses haskell cafe using a free news server, could he say me which one ? Thanks by advance.

3 2

RE: Template Haskell question
by Simon Peyton-Jones 12 Jul '03

12 Jul '03

Yes, sorry, as Ian says, type splices just aren't implemented at the moment. The error message is uninformative. This is useful info though -- someone wants type splices! Simon | -----Original Message----- | From: haskell-cafe-admin(a)haskell.org [mailto:haskell-cafe-admin@haskell.org] On Behalf Of Ashley | Yakeley | Sent: 27 June 2003 23:57 | To: haskell-cafe(a)haskell.org | Subject: Template Haskell question | | Can anyone tell me what's wrong with this? | | -- ghc -fglasgow-exts -c TH.hs | module TH where | { | import Language.Haskell.THSyntax; | | class HasZero a where | { | zero :: a; | }; | | aninstance :: TypQ -> Q [Dec]; | aninstance t = [d| | | instance HasZero $t where -- error here | { | zero = 0; | }; | | |]; | | $(aninstance [t|Int|]) | $(aninstance [t|Integer|]) | } | | | $ ghc -fglasgow-exts -c TH.hs | TH.hs:14: Malformed context in instance header | | All I want to do is spin off a number instances for a number of types... | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1