October 2006 - Haskell-Cafe

getting a DB library working with ghc 6.6 and PostgreSQL 7.4.7
by Seth Gordon 20 Oct '06

20 Oct '06

I'm looking for an alternative to HSQL for database connectivity -- the lack of prepared statements in HSQL is particularly worrisome. I installed HDBC, but when I tried running a simple program that used it, I get the error message ghc-6.6: /usr/local/lib/HDBC-postgresql-1.0.1.0/ghc-6.6/HSHDBC-postgresql-1.0.1.0.o: unknown symbol `PQserverVersion' Looking more closely at the README.txt file there, it seems that the PostgreSQL driver is expecting 8.1, and I'm using 7.4.7. I installed the ODBC driver, and I know that in theory one can connect to my PostgreSQL server with ODBC, but as far as I can tell from the documentation, I would have to configure a separate DSN for every database instance that I would want to connect to, which makes it kind of useless for a utility that any user could pass database names to on the command line. The takusen package looks interesting, but when I checked it out and tried to build it (with "ghc --make -o setup Setup.hs"), I got the error message Setup.hs:6:7: Could not find module `Distribution.Compat.FilePath': it is hidden (in package Cabal-1.1.6) How do I work around these? Is there another library worth looking into?

2 2

[Haskell-cafe] Re: Strictness, order of IO operations: NewCGI & HDBC
by Tim Smith 20 Oct '06

20 Oct '06

Hello, Haskell Cafe. I posted a question a while ago about this, but didn't receive any responses. I'd like to try again. I've got a test case which uses John Goerzen's HDBC.ODBC. The problem I have is that it appears too lazy - using the results of a query after disconnecting causes an "unknown exception". If I use the results before disconnecting, it works fine. module Main where import Data.List (intersperse) import qualified Database.HDBC as DB import Database.HDBC.ODBC (connectODBC) main :: IO () main = do dbh <- connectODBC "DSN=test" res <- DB.getTables dbh -- print (show ((concat . intersperse ", ") res)) DB.disconnect dbh print (show ((concat . intersperse ", ") res)) Compiling and running this will show: $ ./db-discon db-discon: unknown exception If I uncomment the first 'print' line, then it works as expected: $ ./db-discon "\"d1, foo, odbctest\"" "\"d1, foo, odbctest\"" Am I just expecting the wrong thing from Haskell? Is there a technical reason why HDBC can't synchronize the IO so that everything is resolved before the disconnect? Or is this a bug in HDBC? Thanks, Timothy -- If you're not part of the solution, you're part of the precipitate.

4 6

Error building Edison 1.2.0.1
by Lyle Kopnicky 19 Oct '06

19 Oct '06

Hi folks, I tried to build edison-1.2.0.1-sources with the command 'make system' but got: *** Exception: Line 10: Unknown field 'hs-source-dirs' I am using GHC 6.4.1. Any idea how to fix this? Thanks, Lyle

3 13

A better syntax for qualified operators?
by Brian Hulley 19 Oct '06

19 Oct '06

Hi - Consider the scenario when you want to find a function that returns the i'th element of an array but all you know is that there is a module called Data.Array.IArray that will probably have such a function in it. So you start typing in your program: let ith = Data.Array.IArray. at this point, you'd hope the editor you're using would somehow display a list of avaliable values exported from Data.Array.IArray including the indexing function, so you could select it, thus I would *like* to be able to use the syntax: let ith = Data.Array.IArray.(!) because it's not the user's fault that the person who wrote Data.Array.IArray decided to use a symbol instead of an identifier for this function - the user of Data.Array.IArray in this case just wants to see normal identifiers to use with prefix application so the use of (!) at this point effectively gets rid of the unwanted operatorness associated with the function. However the current syntax of Haskell would not allow this. Instead you have to write: let ith = (Data.Array.IArray.!) The problem is that the user of Data.Array.IArray has to know already in advance, before typing the 'D' of "Data", that the indexing function has been named with a symbol instead of an identifier, but this knowledge is only available later, when the user has typed the '.' after "IArray", so the current syntax would be frustrating for the user because the user then has to go all the way back and insert an opening paren before the 'D'. Also, consider the appearance of: let ith = (Data.Array.IArray.!) arr i b = Data.Array.IArray.bounds arr vs let ith = Data.Array.IArray.(!) arr i b = Data.Array.IArray.bounds arr I'm not sure if I've managed to explain this problem clearly enough, but my proposal is that we might consider changing the lexical syntax of Haskell as follows: varId ::= id varOp ::= symbol varIdOp ::= ` varId varOpId ::= ( varOp ) varOpIdOp ::= ` varOpId qvarId ::= {conId .}+ varId -- { }+ denotes 1 or more times qvarIdOp ::= ` qvarId qvarOp ::= {conId .}+ varOp qvarOpId ::= {conId .}+ varOpId qvarOpIdOp ::= `qvarOpId In other words, to turn an operator symbol into an id, the parentheses would be put immediately around the symbol (with no spaces since this is lexical syntax), and to turn an id into an operator the backquote is put in front of the entire (qualified) id. (Also the trailing backquote in the existing syntax is redundant) The above syntax would have 3 advantages: 1) It allows the client of a module to write code without having to worry if the author of the module used symbols or identifiers to name functions - everything exported from the module can be made to appear as if it was named by an identifier (ie OpId) 2) Moving the parentheses to the lexical syntax makes syntax highlighting easier (because there are no comments to worry about inside the OpId) and also makes parsing simpler because all the mess associated with Ops versus Ids is handled by the lexer 3) It allows an editor to make a distinction between (+) -- an operator turned into an identifier - varOpId ( + ) -- an expression with 2 gaps in it which should be marked as incomplete (+ ) -- a section with 1 gap Some examples of the proposed syntax are: let ith = Data.Array.IArray.(!) arr i foo = k `Math.(+) 6 -- default precendence bar = k Math.+ 6 -- using precedence of + in module Math When you try to write an editor for Haskell (or some subset of it), you quickly discover these areas of Haskell syntax like the above which need to be changed to get an optimum interactive editing experience. I think it *is* possible to adjust the Haskell grammar so that it is LL(1) and the only reason it is not already LL(1) seems to be that the grammar has been designed with compilers (which only need to deal with complete modules) in mind rather than programmers interactively editing in mind. (The other change needed for LL(1) is to give contexts a marker before they appear eg: foo :: {MonadIO m} a -> m a ) By LL(1) I'm really meaning that the grammar for interactive editing needs to be adjusted so that it is possible to maintain the invariant that as code is entered from left to right constructs and identifiers can be highlighted according to their grammatical role and highlighting (modulo incompleteness) must remain unchanged regardless of whatever is typed afterwards to the right otherwise it can become more of a liability than a help, hence my hope that some future revision of Haskell grammar might consider taking the above points into account. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

9 14

Thanks !! (was: Newbie and working with IO Int and Int)
by Víctor A. Rodríguez 19 Oct '06

19 Oct '06

I want to thanks you all for your helps regarding this issue. You've been very helpful and comprehensive. Salute !! -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

1 0

Re: [Haskell] Lexically scoped type variables
by Bulat Ziganshin 19 Oct '06

19 Oct '06

Hello Simon, Wednesday, October 18, 2006, 12:09:40 PM, you wrote: > Other alternatives would be: do something about partial type > signatures; or make GADT type inference more sophisticated (and > thereby perhaps less predicatable). just one more problem is that this issue is too complicated. i'm not sure that i correctly understands details, but for me the situation seems like this: in 6.4 it was no distinction between declarations and usages of type variables - first use declared it, while in 6.6 we have exactly defined places to declare type variable. the problem is that sometimes we want to declare variable for one type but the place where it may be declared - function signature - requires to write full type so, if my understanding is correct, may be it's possible to use special syntax for explicit _declaration_ of type variable at any place where it can be used? i mean the following: f (x :: forall a. a) = undefined::a here, we use 'forall' to explicitly declare new type variable. so it is equivalent to the following: f :: forall a. a -> ... f x = undefined::a where '...' used to make partial type signature -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

beginner's problem about lists
by falseep＠gmail.com 19 Oct '06

19 Oct '06

Hi all, I'm trying to implement a function that returns the shorter one of two given lists, something like shorter :: [a] -> [a] -> [a] such that shorter [1..10] [1..5] returns [1..5], and it's okay for shorter [1..5] [2..6] to return either. Simple, right? However, it becomes difficult when dealing with infinite lists, for example, shorter [1..5] (shorter [2..] [3..]) Could this evaluate to [1..5]? I haven't found a proper implementation. Again it's ok for shorter [2..] [3..] to return whatever that can solve the above problem correctly. An infinite list could work, I guess, but I don't know how. Thanks for any help.

17 26

optimization help
by jeff p 18 Oct '06

18 Oct '06

Hello, I have been trying to do some CSV-style processing. My code works fine for small input (up to 10MB), but performs poorly for moderate to large input (it can't seem to finish 100MB of input with 700MB heap space). I have gone through several optimization passes with profiler help, and now I am hoping someone else can point out some other approaches to improving the code's performance (both space and time). The code breaks a large file into smaller files all of whose entries have the same date. thanks, Jeff ------------------------ module Main where import Debug.Trace import Control.Monad import Data.List import qualified Data.ByteString.Lazy.Char8 as B import qualified Data.Map as M import System.Environment (getArgs) dataDir = "dataH/" myRead file = do v <- B.readFile file let (cols' : rows) = map (B.split ',') $ B.lines v let cols = foldl' (\mp (k,v) -> M.insert k v mp) M.empty (zip cols' [0 ..]) return (cols, rows) getColId cols col = M.lookup col cols getCol cols col row = do i <- getColId cols col return $! row!!i dates file nRows = do (cols, rows) <- myRead file let addDate mp row | mp `seq` row `seq` False = undefined | otherwise = do date <- getCol cols (B.pack "\"Date\"") row let old = M.findWithDefault [] date mp return $ M.insert date (row:old) mp res <- foldM addDate M.empty $ take nRows rows mapM_ writeDate $ M.toList res where fmt = B.unpack . B.map (\x -> if x == '-' then '_' else x) . B.takeWhile (/= ' ') writeDate (date,rows) = B.writeFile (dataDir++fmt date) (B.unlines $ map (B.join (B.pack ",")) rows) main = do args <- getArgs case args of ["dates",file,nRows] -> dates file (read nRows)

4 16

Re: Lexically scoped type variables
by apfelmus＠quantentunnel.de 18 Oct '06

18 Oct '06

I think the problem comes from the fact that let (x :: a) = rhs in expr has two interpretations: either the programmer mainly specifies a judgment (\Gamma |- rhs :: a) (f.i. as a guide for type inference) or he just introduces a new variable and sees let as a sugar for (\(x :: a) -> expr) rhs with the viewpoint that the program is a huge expression and all top-level declarations are just (somewhat superflous) lambdas which lead to a final goal. In both cases, one would assume that the main variable binder is our good old lambda. Thus, the (::) in (\(x::a) -> ..) behaves like a constructor and the type variable on the right hand side is just a pattern: f (x :: [a]) = ... is not any different from f (Cons x [a]) = ... When f is applied to an argument, it's the type checker that performs "pattern matching". Of course, one needs nonlinear "type patterns": (f :: a -> b) $ (x :: a) = f x So the type variables in lambdas behaves like normal variables and things like g :: Int -> Int g (x :: a) = x + 1 :: a are entirely fine. All in all, type variables in lambdas are real variables. The first interpretation of let amounts to the Haskell98 intuition: the code x :: a -> a x = rhs means a judgment that x has type (forall . a -> a). This also means that this does not bring any new type variables in scope, only lambdas are capable of introducing new variables. GHC 6.6 rules are not compatible with that. They somehow admit variable bindings by judgments only to discover that this doesn't work for existential types. But note that we have (x :: ...) and (x=...) as separate statements, and we may well keep the second interpretation: f :: Int -> Int (f :: a -> a) = \x -> (x+1 :: a) The intuition is that stand-alone statements (x :: ...) are exactly what they look like: judgments for the type system. The only odd thing about them is that they are stand-alone and do not add to the "main program expression". IMHO, the most natural thing would be that type judgments appear on the rhs of a let or a lambda and that type variable bindings appear on the lhs of a let or a lambda. In the definition of f above, (f :: Int -> Int) and (x+1 :: a) are judgments and (f :: a -> a) is a variable binding. Any confusion between judgment and binding is just like a confusion between constructor application and pattern. Regards, apfelmus

1 0

Re: [Haskell-cafe] Newbie and working with IO Int and Int
by Víctor A. Rodríguez 18 Oct '06

18 Oct '06

> What's wrong with doing it this way? > > -- ** UNTESTED CODE ** > > verifyAdd :: Int -> Int -> Int -> Bool > verifyAdd a b sum | a + b == sum = True > otherwise = False > > testAddMundane :: Int -> Int -> Bool > testAddMundane a b = verifyAdd a b (a + b) > > -- all the IO-dependent stuff is below this line -- > > testAddRandom :: IO Bool > testAddRandom = do a <- randomIO > b <- randomIO > return verifyAdd a b (a + b) > I discovered something worst yet :-P Using the next code and calling verifyAdd or testAddMundane it says : Program error: verifyAdd: ERROR Instead calling testAddRandom only says : :: IO Bool (55 reductions, 92 cells) ---- CODE STARTS HERE, AND IS TESTED ----- import Random verifyAdd :: Int -> Int -> Int -> Bool verifyAdd a b sum = error "verifyAdd: ERROR" testAddMundane :: Int -> Int -> Bool testAddMundane a b = verifyAdd a b (a + b) -- all the IO-dependent stuff is below this line -- testAddRandom :: IO Bool testAddRandom = do a <- randomIO b <- randomIO return ( verifyAdd a b (a+b) ) -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

4 4