March 2007 - Haskell-Cafe

MPTCs and rigid variables
by David House 07 Mar '07

07 Mar '07

class Foo a b | a -> b instance Foo Int String bar :: Foo Int b => b bar = "rargh" Is there any reason why that shouldn't work? GHC gives one of its silly "b is a rigid variable" errors (aside: that's a really confusing error; I'd prefer something like Hugs's "Infered type is not general enough"). -- -David House, dmhouse(a)gmail.com

9 16

ANN: Bugfixes for regex-posix and regex-pcre ByteString use
by Chris Kuklewicz 07 Mar '07

07 Mar '07

I got a bug report from the #haskell IRC channel last night that empty ByteStrings were broken. The new bugfixed versions of the affected packages are: regex-posix-0.92 regex-posix-0.72 regex-pcre-0.92 regex-pcre-0.81 All the above have been uploaded to http://hackage.haskell.org/ and are available via darcs (see below). Details: regex-posix-0.92 replaces the "unstable" regex-posix-0.91 that I announced yesterday. The bug fix also applied to ByteString.Lazy repository: http://darcs.haskell.org/packages/regex-unstable/regex-posix/ regex-posix-0.72 replaces the regex-posix-0.71 that came with GHC 6.6 repository: http://darcs.haskell.org/packages/regex-posix/ The repository version is setup to compile alongside GHC in some way that I cannot easily package, so the tarball on hackage has edited Wrap.hsc and cabal files. regex-pcre-0.92 replaces the "unstable" regex-pcre-0.91 that I announced yesterday. The bug fix also applied to ByteString.Lazy repository: http://darcs.haskell.org/packages/regex-unstable/regex-pcre/ regex-pcre-0.81 replaces the "stable" regex-pcre-0.80 that is compatible with the regex-base-0.71 supplied with GHC or regex-base-0.72 that I announced yesterday. repository: http://darcs.haskell.org/packages/regex-pcre/

3 3

LGPL libraries
by Alex Queiroz 07 Mar '07

07 Mar '07

Hallo, Gtk2Hs and HDBC are both LGPL licensed, but aren't they always static linked? Is there a way to use them in closed-source programs? Cheers, -- -alex http://www.ventonegro.org/

13 15

Haskell File reading
by cornmouse 07 Mar '07

07 Mar '07

I have a txt file, which contains a paragraph. I am trying to read the file, and pass the contents of the file as a string to another function called "createIndex". "createIndex" is a function to generate index of the input string. Below is my code to read the file : main :: IO () main = do putStr "Enter input file name.txt: " filename <- getLine content <- readFile filename createIndex content createIndex :: String -> [ ([Int], String) ] createIndex {- contents of the function... -} I am using Hugs compiler, when i execute, i got an error Type error in generator *** Term : showString content *** Type : [Char] -> [Char] *** Does not match : IO a IO> I know the data type doesn't match. How do i go about this?

4 3

Re: [Haskell] Haddock not being able to read interface file
by Simon Marlow 07 Mar '07

07 Mar '07

Wolfgang Jeltsch wrote: > Am Dienstag, 6. März 2007 12:09 schrieben Sie: >> Wolfgang Jeltsch wrote: >> […] > >>> However, Haddock outputs the following: >>> >>> haddock: Warning: The interface file "base.haddock" could not be >>> read. Maybe it's from a later version of Haddock? >>> >>> This happens with Haddock 0.8 as well as the current development version >>> of Haddock. >> It's possible the interface files are not portable between 32 and 64-bit >> machines, and you're using one generated for a different word size. I >> haven't verified this, but I'll make a note to check for the next version >> of Haddock. I imagine we'll move to using Data.Binary anyway, which should >> fix any non-portability issues. > > Hello Simon, > > I use a 64 bit machine. Was base.haddock on the Haskell website created on a > 32 bit machine? I don't honestly know, it could have been either. Cheers, Simon

1 0

Haskell Cookbook?
by Alexy Khrabrov 07 Mar '07

07 Mar '07

So I'm picking up Haskell bit by bit, and I found the code examples transpiring here most useful. Reflecting why it's harder to pick up Haskell than say Ruby or Python, here's what I found -- those languages deal with a typical domain available to any programmer -- his own computer/system/shell. The artifacts are files, directories, timestamps, etc. The stuff every programmer understands in their sleep. APIs. So I loved the shell-script beautification thread. That's how I learn about new modules and their functions -- as use cases. I also found some pieces of Haskell strewn around people's websites, blogs, forums; even at paste.lisp.org. I'm gathering them for my own purpose and trying to compile and run them. Wouldn't it be nice -- in case it doesn't exist already -- a[n O'Reilly[-like]] Haskell Cookbook? That would be the best way to learn Haskell. I've found a wikibook on Haskell, but I look for a big bag of small, self-contained programs. Perhaps you esteemed veterans can dig your small scripts and paste them into a wiki? Examples needed -- how to connect to a database; to a web service (e.g. Amazon); read a csv file; represent data equivalent to a directory listing; a text file/XML; etc... Cheers, Alexy

8 10

Programming performance
by Tim Newsham 06 Mar '07

06 Mar '07

I'm interested in understanding how fast people can program small utility and experiment type programs in haskell. I'm also interested in seeing what types of solutions people who are experienced and code quickly end up with. Towards this end I set up a small informal experiment on the wiki: http://www.haskell.org/haskellwiki/Programming_performance Hopefully the problem is small, fun and easy without being too unrealistic. and a question about the wiki/page: is there a simple way to host the input data on the wiki? Tim Newsham http://www.thenewsh.com/~newsham/

2 1

weak references and sharing
by Thomas Conway 06 Mar '07

06 Mar '07

Hi All, I have the situation where I have something like the following: type Foo = TVar Int data Clasp t = Clasp t makeClasp x f = do let c = Clasp x mkWeakRef c (Just (f x)) return c finis p = do atomically $ do x <- readTVar p writeTVar p (x - 1) .... makeClasp p finis .... The Foo object has a greater lifetime than the Clasp. The bit I want you to focus on is the three lines: let c = Clasp x mkWeakRef c (Just (f x)) return c We can only be sure that (f x) will be called after we let go of the returned value if we can be sure that the language implementation preserves the (explicit) sharing of 'c' between the call to mkWeakRef and return. In particular, if the implementation rewrote the fragment as: mkWeakRef (Clasp x) (Just (f x)) return (Clasp x) then the finalizer might be called sooner than we expect. The problem is, that as I read it, making a distinction between the two fragments would be a violation of referential transparency. So here's the question: is there a way of writing this that is guaranteed to work on all correct implementations of Haskell? cheers, T. ps FWIW, the actual situation is that we have a TVar pointing to a record representing a 'page' of an external data structure. For some operations we need to make sure the the page is in-memory, but when all the operations using a particular page are finished, we'd like to flush it back to disk if it has been modified. Now it'd be really nice to use the garbage collector to tell us when noone is using the in-memory version of the page, so we can write it out. However, if we can't be certain that we've got a genuine hard-reference to the object, then we can't be sure it will not be prematurely flushed. -- Dr Thomas Conway You are beautiful; but learn to work, drtomc(a)gmail.com for you cannot eat your beauty. -- Congo proverb

1 0

IO and lazyness.
by D.V. 06 Mar '07

06 Mar '07

Hello, I'm still learning Haskell and I am stuck on a probably simple problem. Assume I have a file where lines are of the form "key=value" I want to search a value in that file and came up with the following code. > rechf :: String -> IO (Maybe String) > rechf r = bracket (openFile "liste" ReadMode) (hClose) (rechf2 r) > > rechf2 :: String -> Handle -> IO (Maybe String) > rechf2 r h= do > f <- hGetContents h > --print f > return $ rech r $ lines f > > rech :: String -> [ String ] -> Maybe String > rech r l = lookup r $ map span2 l > > span2 :: String->(String,String) > span2 c = (a,b) > where a=takeWhile (/='=') c > b=drop 1 $ dropWhile (/='=') c Now the problem is this : 1) if I try rechf, it returns nothing even for a key that exists in the file. 2) if I uncomment the line where there is "print f", the key is found and the value returned. I'm guessing print forces f to be evaluated, so the file is actually read, but I was wondering why it doesn't work without it and how to correct that. David.

8 11

Literate haskell format unclear (implementation and specification inconsistencies)
by Isaac Dupree 06 Mar '07

06 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trying to implement literate haskell[*], I realized several ways in which the correct behavior for unliterating (especially with regard to errors) was unclear. I have several cases which ghc, hugs and Haskell 98 have differing opinions on! The Report as it stands is far from a clear and complete specification (and I didn't find anything in the Haskell' wiki/trac about literate haskell). [*](particularly, to make DrIFT able to deal with TeX-style lhs - there's unfinished work in darcs repo http://isaac.cedarswampstudios.org/2007/DrIFT/ ) testing with: ghc: 6.4.2, 6.6(some) hugs: Hugs Version 20050308 nhc98: recent darcs (1.19) report: Haskell 98 (The Revised Report: December 2002), section 9.4, http://www.haskell.org/onlinereport/syntax-iso.html#sect9.4 A full set of .lhs test files for all the issues: darcs get http://isaac.cedarswampstudios.org/2007/LiterateHaskellTests or download http://isaac.cedarswampstudios.org/2007/LiterateHaskellTests-1.tar.gz or you can try just prefixing all examples with \begin{code} module Main where main = print str \end{code} or >module Main where > main = print str as appropriate... (please don't get mangled by mail programs, initial '>'s... ): 1.[UnmatchedBegin] If a \begin{code} starts a section of code, is \end{code} _required_ before the end of the file? report: unclear ghc: required hugs, nhc98: not required The report says "entirely enclosed between", but goes on to say "More precisely:" and give a description that is not at all precise in the matter of this question. 2.[AfterBeginOrEnd/{BeginWhite,EndWhite,BeginPrint,EndPrint}] Can a line beginning \begin{code} or \end{code} have additional stuff on the end, where the directive is understood and the additional stuff is ignored? report:[yes] hugs:[yesIffAdditionalStuffIsInvisible] ghc:[case beginningOfLine of "\end{code}" -> yes "\begin{code}" -> yesIffAdditionalStuffIsInvisible] nhc98:[UNLIT_IGNORED] where yesIffAdditionalStuffIsInvisible = if (all isSpace additionalStuff) then yes else UNLIT_IGNORED UNLIT_IGNORED means that if it was inside a code block then the line is treated as program text (so it's probably a syntax error) and if it was in a literate comment section it is treated as a non-empty literate comment line. Note that it takes a careful reading of the report: for begin, program code only begins on the _following_ line. Most seem to agree that it shouldn't mess up your program to have trailing whitespace on such a line (but at least nhc98 doesn't currently implement this). Is there any reason to allow NON-whitespace in that location? 3.[IgnoringStringLiterals/{A,B}] what does "(ignoring string literals, of course)" mean? that the following(A) makes str = "string gap:end{code}" and an unended code block(A), or that it makes an ended code block(B)? (A)--------- \begin{code} str = "string gap:\ \end{code}" - --------- report:unclear, hugs:A, ghc:B, nhc98:A This works for ghc, the result being "string gap:string gap ends": (B)--------- \begin{code} str = "string gap:\ \end{code}" \begin{code} \string gap ends" \end{code} - ----------- Note that behavior 1 requires a detailed knowledge of Haskell's syntax in order to unliterate a file, for a dubious benefit (if a string literal with string gaps is used like that, the programmer could just indent the second line!) 4.[ExtraBeginEnd/{ExtraBegin,ExtraEnd}] What happens if \begin{code} appears after another \begin{code} before an \end{code}; and what happens if an \end{code} appears without a code block previously having been started by a \begin{code}? stray end: ghc, nhc98:[UNLIT_IGNORED (-> probable successful compile)] hugs:[error "\end{code} encountered outside code block"] stray begin: ghc, nhc98:[UNLIT_IGNORED (-> probable syntax error)] hugs:[error "\begin{code} encountered inside code block"] 5.[LexicalUnitAcrossLiterateComment/{StringGap,BlockComment}] Can lexical units jump across literate comment gaps? report, ghc, hugs, nhc98: yes... Note that the Report specifies it by removing all non-program lines, rather than converting them to blank lines, but an additional blank line in the middle of a Haskell program NEVER makes a difference (except for line numbering, of course). - ---------- > str = "string gap:\ This might be a literate comment. > \ends here" - --------- ghc, hugs, nhc98: "string gap:ends here" or - -------- > str = "string" > {- a comment This might be a literate comment -} with weird character sequences. > ends here -} - ---------- ghc, hugs, nhc98: think it's a fine comment I mention this because allowing these makes it complicated to preserve literate comments in a translation to .hs, because, other than cases like these, prefixing literate comment lines with "-- " works fine.[*] However, banning these could make processing that wants to report errors end up more complicated. Maybe the report could/should say that it is "not advisable", as it does for mixing '>' and {code} styles? (Also it's confusing to the programmer - I wondered "can I (and should I) really do that?!" sometimes..) [*]Haddock style is a nuisance too, which is why there are two spaces added -- Haddock seems not to recognize such comments then, as desired. Or would it be better to take the other approach and say those should count as haddock comments? 6.[TeXBirdtrack/] I understand that "It is not advisable to mix these two styles in the same file." and the report doesn't even talk about how they mix, but now that I've gotten started on the implementation inconsistencies... Actually, despite the Report's advice against it, there seems to be a consensus on what the meaning of mixing the two styles is, which I'll describe below: Sensibly, ghc, hugs and nhc98 treat begin/end{code} lines as blank for the purposes of '>'-style comment checking (which is that a code and a non-blank literate comment line can't be adjacent); this works: [TeXBirdtrack/NoLayout]------------ >module Main where >{main = print str \begin{code} ;str = "string"} \end{code} ok - ------------ Note I didn't rely on the layout rule. This should work: [TeXBirdtrack/AlignedLayout]------------ >module Main where > main = print str \begin{code} str = "string" \end{code} ok - ------------ It does in hugs and nhc98, and according to http://hackage.haskell.org/trac/ghc/ticket/210 it does in GHC HEAD now (6.7) as well. As another example, this doesn't work, for the same reason that you can't start a line with '>' in a .hs file: [TeXBirdtrack/Wrong]------------ >module Main where > main = print str \begin{code} > str = "string" \end{code} ok - ------------ Hoping to start some discussion, Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5gaoHgcxvIWYTTURAoF4AJwIjQ3hJ9jpwUgHiYgTB7IhN2so4QCdGCKU 96q4YIeakWtlBKOdAiFM+vU= =qzCQ -----END PGP SIGNATURE-----

5 8