July 2006 - Haskell-Cafe

Problems installing HDBC-postgresql
by Martin Percossi 12 Jul '06

12 Jul '06

Hi, I'm having problems using HDBC-postgresql (I've tried both 0.99.2.1 and 1.0.0.0) with postgresql (version 8.1.4, installed in /share/pgsql). I adjust the include-dir and extra-lib-dirs to use the custom location of postgresql, and build: no error messages, everything seems fine. However, when I then try to type: ghci -package HDBC -package HDBC-postgresql , I get the error message: Loading package HDBC-postgresql-0.99.2.1 ... linking ... ghc-6.4.2: /home/mpercossi/opt/lib/HDBC-postgresql-0.99.2.1/HSHDBC-postgresql-0.99.2.1.o: unknown symbol `PQserverVersion' ghc-6.4.2: unable to load package `HDBC-postgresql-0.99.2.1' Has anyone seen this error message before? Google didn't turn up anything relevant to haskell -- however there does seem to be a PQserverVersion procedure in the libpq library -- maybe HDBC-postgresql is not seeing this due to the custom install location? TIA Martin

2 2

technique to allow innocuous ambiguity in instance declarations?
by Nicolas Frisby 12 Jul '06

12 Jul '06

Brief disclaimer: I'm using GHC 6.4.1 and haven't looked into Hugs; but I don't suspect there's much difference on this issue. Could easily be wrong there. I've hit a bit of a road bump in ambiguity regarding type class instances and transformer types (in the style of monad transformers). The interesting point is that, in this case, I believe that the ambiguity is harmless and that all possible derivations of instances would be extensionally equivalent. But the typechecker won't let me get far enough to test that hypothesis. So, I have a relation C and intuition that the property can be carried through transformations on either of its related types. I'm seeking 1) a suggested technique for formulating that intuition in such a way that the type-checker could act on it 2) a suggestion claiming that such a harmless ambiguity is down right impossible Below is pseudo-code outlining the shape of my problem. Consider a 2 parameter (both are type constructors) class: > class C f g where > nest :: f a -> g a I have instances for base types (analogous to the Identity monad). > class C IdL IdR where > nest = ... I also have transformers that I can apply to these base types and instances that correspond to "lifting" the C type class property through the transformers. > class C f g => C f (TransR g) where > nest = ... code that involves the "nest" of the C f g instance ... or > class C f g => C (TransL f) g where > nest = ... code that involves the "nest" of the C f g instance ... The simple version of my issue is that, give the instances so far, the compiler won't derive an instance for T. > type T = C (TransL IdL) (TransR IdR) The impasse is the ambiguity in the derivation from C IdL IdR to T. One could apply first TransL or apply first TransR. The "-fallow-overlapping-instances" type system extension fails to help because there is no "most specific" instance. The order of application of my transformers (i.e. transforming the left or transforming the right parameter) does not seem to matter--I have found no intuition that says the derivations ought to be distinguishable in anyway. My question: Is there a technique to allow such innocuous ambiguity in instance declarations? I experimented with introducing something akin to a trace in a third parameter to the class which would disambiguate the derivation (by specifying the order of the transformations; reminded me of "Strongly typed heterogeneous collections"), but had no luck there (perhaps someone else would). Because the ambiguity does not matter to me, I'd be fine implementing a rule such as "always transform the left parameter first", but I don't know how to/if I can formulate that in Haskell. I also tried to reduce the class to a single parameter, which incorporated the the functors into a single type. The method of the class needs those functor types available, so that approach sputtered out. Another issue is modularity: both of my attempts above would have bloated the code using the class with the details needed to disambiguate it. I certainly prefer the context "C f g" to one that exposes the disambiguation. That is, I would highly prefer a solution that allows h1 instead of h2. > h1 :: C f g => a type > h1 = ... some code with nest ... > h2 :: (C f g, DisambiguationHelper f g ?) => a type > h2 = ... some code with nest ... My harrowing suspicion is that I will need to split the property into two--something I can't readily see how to do. Thanks for your time, Nick

2 1

comdlg32.dll FFI bindings
by Jason Dagit 11 Jul '06

11 Jul '06

Hello, I was planning to create FFI bindings for GHC to be able to use comdlg32.dll and I just realized I should ask if others have already done this. I figure I'll probably just code it up by hand assuming I can find suitable documentation but if there is a tool that can generate this automatically that would be even better. Thanks, Jason

3 3

Re: Why is there no splitBy in the list module?
by Yitzchak Gale 11 Jul '06

11 Jul '06

I personally use split :: Eq a => [a] -> [a] -> [[a]] all the time, much more often than splitBy :: (a -> Bool) -> [a] -> [[a]] But I don't call it "split". By analogy with concatMap, the Haskell analogue of Perl/Python "join" is concatIntersperse. Then, by analogy with lines/unlines, the Haskell analogue of "split" is... unconcatIntersperse. Hmm...

2 1

Defining show for a function type.
by Johan Grönqvist 11 Jul '06

11 Jul '06

I am a haskell-beginner and I wish to write a Forth-like interpreter. (Only for practice, no usefulness.) I would like use a list (as stack) that can contain several kinds of values. data Element = Int Int | Float Float | Func : Machine -> Machine | ... Now I would like to have this type be an instance of the class Show, so that I can see what the stack contains in ghci. "deriving Show" is impossible as Func is not instance of Show. Can I make it instance of Show? I just want to define something like show (Func _) = "Function, cannot show" and I am not interested in actually displaying any information about the function, but I am interested in getting information about elements of other kinds. So far I have just guessed, but failed to produce anything that does not give an error stating that my function is not of the form (T a b c) where T is not an alias and a b c are simple type variables (or so). Any help appreciated! Johan

7 7

Re: [Haskell-cafe] Re: Why is there no splitBy in the list module?
by Donn Cave 11 Jul '06

11 Jul '06

Quoth John Meacham <john(a)repetae.net>: ... | just a note: I find splitBy a much nicer routine to provide. | |> splitBy :: (a -> Bool) -- ^ whether char is a separator |> -> [a] -- ^ list to split |> -> [[a]] Starting from the assumption that in most cases the list to be split will be [Char], so we can reasonably hold this up against string functions in other languages -- I think split is commonly split :: String -> String -> [String] i.e., the separator is [a], not a. Of course next they'll want regular expressions, but I use string separators of length > 1 a lot and rarely bother with regexps. But string splitBy might be an interesting alternative to regexp splits. Something like splitBy :: ([a] -> Maybe Int) -> [a] -> [[a]] breakBy :: ([a] -> Maybe Int) -> [a] -> Maybe ([a], [a]) breakBy f s = by [] f s where by _ _ [] = Nothing by c f s@(a:ax) = case f s of Just n -> Just ((reverse c), (drop n s)) Nothing -> by (a:c) f ax splitBy f s = case breakBy f s of Just (l, r) -> l:(splitBy f r) Nothing -> [s] Where in the simplest case the matching function would simply compare with a separator string, but could easily do more - eat up trailing blanks, for example. Note use of Maybe, basically to disambiguate end of data with and without match. Donn Cave, donn(a)drizzle.com

1 0

Re: [Haskell-cafe] type dependency
by Donn Cave 11 Jul '06

11 Jul '06

Quoth Henning Thielemann <lemming(a)henning-thielemann.de>: ... | Will you make that plotter wrapper public? Why not - I don't expect it's going to be big news in the computing world, but it's easy to set the files up. See http://staff.washington.edu/donn/ezp/hsezp.html Thanks to Bulat for the tip on multi-parameter typeclass. Donn Cave, donn(a)drizzle.com

1 0

Help building HSQL...
by Martin Percossi 10 Jul '06

10 Jul '06

Hi, I'm trying to build HSQL, in order to use HaskellDb. The base directory (i.e. HSQL) builds ok, as per instructions, but the PostgreSQL directory fails with the error message: Setup.lhs:17:71: Couldn't match `PackageDescription' against `LocalBuildInfo' Expected type: Args -> ConfigFlags -> LocalBuildInfo -> IO ExitCode Inferred type: [String] -> ConfigFlags -> PackageDescription -> LocalBuildInfo -> IO ExitCode In the `postConf' field of a record In the record update: defaultUserHooks {preConf = preConf, postConf = postConf} My version of ghc is 6.4.2. My installed packages are (using "ghc-pkg list"): Cabal-1.0, (Cabal-1.1.4), GLUT-2.0, HUnit-1.1, MissingH-0.14.2, OpenGL-2.0, QuickCheck-1.0, base-1.0, (concurrent-1.0), (data-1.0), fgl-5.2, haskell-src-1.0, haskell98-1.0, hsql-1.7, (hssource-1.0), (lang-1.0), mtl-1.0, (net-1.0), network-1.0, parsec-1.0, (posix-1.0), readline-1.0, rts-1.0, stm-1.0, template-haskell-1.0, (text-1.0), unix-1.0, (util-1.0) Note that I have installed all of these packages, and ghc into my ~/opt directory, as I don't have root. Has anyone seen the above error message before? Am I using the incorrect version of Cabal? Any help appreciated. TIA Martin

2 1

lists as instances of a class?
by David Roundy 10 Jul '06

10 Jul '06

(This email is a literate haskell program that fails to compile without -fglasgow-exts.) I'm sure I'm missing something lame here, but can someone tell me why we apparently can't declare a list to be an instance of a class in Haskell 98? Or is there perhaps some other syntax by which I'd declare this instance? If so, is this slated for fixing in Haskell'? $ ghc Test.lhs Test.lhs:6:1: Illegal instance declaration for `Vec [Double]' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Vec [Double]' > module Vec where > class Vec v where > (.+.) :: v -> v -> v > instance Vec [Double] where > xs .+. ys = zipWith (+) xs ys > instance Vec Double where > x .+. y = x + y feeling very stupid, David P.S. This is with ghc 6.4.1. And oddly enough, if you make the instance instance Num a => Vec [a] where xs .+. ys = zipWith (+) xs ys it works fine, but this strikes me as quite an ugly hack. I really want only Doubles to be instances of this class (which I've abbreviated for this email).

7 6

question about haskell wiki copy-rights
by Bulat Ziganshin 10 Jul '06

10 Jul '06

Hello haskell-cafe, i plan to write sometimes a Haskell performance tutorial. am i correctly understand that i can include contents of existing haskell wiki pages as long as tutorial will be published only on haskell wiki? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2