- Haskell-Cafe - Haskell.org

Literate Haskell source files. How do I turn them into something I can read?
by Michael T. Richter 08 Jan '07

08 Jan '07

I'm trying to wrap my mind around the darcs source code as a preliminary to looking into GHC's guts. All of darcs is written as .lhs files which have bizarre mark-up in them which distracts me from the actual Haskell source I'm trying to figure out and get used to. Apparently the GHC compiler can take .lhs files, strip them with "unlit" (a utility which I finally found buried deep in the GHC installation -- off-path) and then compile them normally. The problem I have is that unlit leaves behind instead these huge gaping (and highly distracting) stretches of whitespace while it takes out the markup. Are there any tools which I can use to render .lhs files readable? I'm fine with having them converted into documented source (i.e. source code embedded in documentation) or as pure Haskell source (but without the huge whitespace gaps) -- but I can't figure out how to get either. -- Michael T. Richter Email: ttmrichter(a)gmail.com, mtr1966(a)hotpop.com MSN: ttmrichter(a)hotmail.com, mtr1966(a)hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr1966(a)jabber.cn "I think it is very beautiful for the poor to accept their lot [...]. I think the world is being much helped by the suffering of the poor people." --Mother Theresa

8 11

Why does the wiki search facility not work properly?
by Brian Hulley 07 Jan '07

07 Jan '07

Hi, There is a page on the Haskell Wiki titled "Talk:SantaClausProblem" subtitled "Beautiful concurrency". However typing any of the following into the search box *doesn't* lead to the page: Santa talk:santaclausproblem beautiful beautiful concurrency Talk:Santa In fact to get the page you have to type the *exact* full title in the *exact* case. Luckily I could always refer back to SimonPJ's post to the Haskell mailing list to find the link to the page, but I think this situation is really bad because it means that things on the wiki are more or less just being thrown down a gaping void never to be seen again unless you know which catagories to look in from the main page. Another point is that the word "beautiful" does occur on the page but the page is not included in the list of page text matches. Perhaps the site is not being automatically re-indexed frequently enough? There is also a bunch of check boxes at the bottom of the search results page that doesn't seem to do anything either except cause nothing at all to happen when you click search unless the (Main) box is the only box ticked. Anyway I thought I'd just point this out in case anyone knows how to fix it. Thanks, Brian. -- http://www.metamilk.com

4 4

less than helpful GHC error message
by Nicolas Frisby 07 Jan '07

07 Jan '07

Consider the terminal session at the bottom of this message. The extra "xc" in Test.hs was the result of me missing CTRL during an Emacs command (I'm guessing...). Unfortunately this took 30 minutes to find since I had far more than two modules and the error message doesn't point this out. Sure it's a silly mistake to make, but I'm guessing it's pretty common. I'm running GHC 6.6 on a PPC Mac. I know pragmas are wierd things, but could this error message be improved? Thanks, Nick $ head -n 10000 Main.hs Test.hs ==> Main.hs <== module Main where import Test main = test ==> Test.hs <== xc{-# OPTIONS -fglasgow-exts #-} module Test where test = putStrLn "weee" $ ghc --make Main <no location info>: file name does not match module name `Main'

2 1

build error with happy-1.15 on ghc-6.6
by Yang 07 Jan '07

07 Jan '07

per a previous thread, i addressed the 'package lang not found' issue by changing the following lines to: $ grep -rsn '\blang\b' . | grep Makefile ./happy/src/Makefile:27:SRC_HC_OPTS += #-package lang ./happy/tests/Makefile:62:HC_OPTS += -fglasgow-exts # -package lang however i still get a build error, seemingly from LALR.lhs: /usr/local/bin/ghc -H16m -O -cpp -fglasgow-exts -O -c LALR.lhs -o LALR.o -ohi LALR.hi LALR.lhs:626:34: Not in scope: `bounds' i wasn't able to find 'bounds' defined in any other of the src files. thanks in advance for any help.

2 1

Re: [Haskell-cafe] Seeking advice on a style question
by Steve Schafer 07 Jan '07

07 Jan '07

On Tue, 26 Dec 2006 20:21:45 -0800, you wrote: >How would this example look if you named only multiply-used expressions? >I'd like to see it in a more conventional pointful style with nested >expressions. I'm still wondering whether the awkwardness results from your >writing style or is more inherent. Showing the real variable names may also >help also. This is what it looks like "for real": > process :: Item -> MediaKind -> MediaSize -> Language -> SFO > process item mediaKind mediaSize language = > let pagemaster = loadPagemaster item mediaKind mediaSize; > questions = stripUndisplayedQuestions mediaKind $ > appendEndQuestions item pagemaster $ > coalesceParentedQuestions $ > validateQuestionContent $ > loadQuestions item; > (numberedQuestions,questionCategories) = numberQuestions pagemaster questions; > numberedQuestions' = coalesceNAQuestions numberedQuestions; > (bands,sequenceLayouts) = buildLayout mediaKind language numberedQuestions'; > bands' = resolveCrossReferences bands; > groupedBands = groupBands bands'; > pages = paginate item mediaKind mediaSize pagemaster groupedBands; > pages' = combineRows pages; > sfo = pages' sequenceLayouts; > in sfo These are the function signatures: > loadPagemaster :: Item -> MediaKind -> MediaSize -> Pagemaster > loadQuestions :: Item -> [Question] > validateQuestionContent :: [Question] -> [Question] > coalesceParentedQuestions :: [Question] -> [Question] > appendEndQuestions :: Item -> Pagemaster -> [Question] -> [Question] > stripUndisplayedQuestions :: MediaKind -> [Question] -> [Question] > numberQuestions :: Pagemaster -> [Question] -> ([NumberedQuestion],[QuestionCategory]) > coalesceNAQuestions :: [NumberedQuestion] -> [NumberedQuestion] > buildLayout :: MediaKind -> Language -> [NumberedQuestion] -> ([Band],[SequenceLayout]) > resolveCrossReferences :: [Band] -> [Band] > groupBands :: [Band] -> [[Band]] > paginate :: Item -> MediaKind -> MediaSize -> Pagemaster -> [[Band]] -> [Page] > combineRows :: [Page] -> [Page] > createSFO :: [Page] -> [SequenceLayout] -> SFO MediaKind, MediaSize and Language are simple enumerations; everything else is a complex structure. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/

4 7

Stupid newbie question
by Brian Hurt 06 Jan '07

06 Jan '07

My apologies for wasting bandwidth on what I'm sure is a stupid newbie question. Given: -- Reimplementing the wheel here, I know data Option a = Some a | Empty deriving (Eq,Ord,Show,Read) nth 0 (x:xs) = Some x nth i (x:xs) = if i < 0 then Empty else nth (i-1) xs nth i [] = Empty That: nth 1000000 [1..10000000] returns the right answer, while: nth 1000000 [1..] blows stack. Furthermore, given: makelist i = i : (makelist (i-1)) Why is it that: nth 1000000 (makelist 1) blows stack? What are the rules for being tail recursive in Haskell? I'm an Ocaml programmer, so I'm familiar with this problem, I just don't see the solution. Some help would be appreciated. Thanks in advance, Brian

8 14

MVar style question
by Chad Scherrer 05 Jan '07

05 Jan '07

When using MVars, is there a reason to prefer using MVar (a,b) over (MVar a, MVar b), or vice versa? I'm not sure if this is really a question of style, or if there are practial implications I'm missing one way or another. Thanks! -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

4 5

Composing functions with runST
by Yitzchak Gale 05 Jan '07

05 Jan '07

Can anyone explain the following behavior (GHCi 6.6): Prelude Control.Monad.ST> runST (return 42) 42 Prelude Control.Monad.ST> (runST . return) 42 <interactive>:1:9: Couldn't match expected type `forall s. ST s a' against inferred type `m a1' In the second argument of `(.)', namely `return' In the expression: (runST . return) 42 In the definition of `it': it = (runST . return) 42 Thanks, Yitz

16 32

RE: [Haskell] Re: state of HaXml?
by Simon Marlow 05 Jan '07

05 Jan '07

[ moving to haskell-café... ] Norman Ramsey wrote: > > There seems to be a misunderstanding here: readFile in > itself is not the > > solution. readFile is defined thus: > > > > readFile name = openFile name ReadMode >>= hGetContents > > > and the original code was this: > > > > load fn = do handle <- IO.openFile fn IO.ReadMode > > contents <- IO.hGetContents handle > > IO.hClose handle > > return $ XP.xmlParse fn contents > > > Sure, you can replace the openFile/hGetContents pair by > readFile, but the > > real problem is the presence of the hClose. Removing that > will solve your > > problem (but note that you now have no control over when > the file is > > actually closed). > > Can I just leave it hanging and rely on the garbage collector to > close it in the fullness of time? Yes. The problem I was alluding to arises when you have many lazilly-closed files, and you run into the system's open file limit because the runtime doesn't close them eagerly enough. To be sure of closing the file at the right time, you need to force the entire file to be read (e.g. by forcing the result of the parse), then close the handle. > Because of laziness, I believe there's no point in my writing the > following: > > > load fn = do handle <- IO.openFile fn IO.ReadMode > > contents <- IO.hGetContents handle > > let xml = XP.xmlParse fn contents > > IO.hClose handle > > return xml > > Is that correct? Yes. Cheers, Simon

1 0

Re: [Haskell] Re: state of HaXml?
by dons＠cse.unsw.edu.au 05 Jan '07

05 Jan '07

nr: > > Sure, you can replace the openFile/hGetContents pair by readFile, but the > > real problem is the presence of the hClose. Removing that will solve your > > problem (but note that you now have no control over when the file is > > actually closed). > > Can I just leave it hanging and rely on the garbage collector to close > it in the fullness of time? Yeah, once your program has demanded the entire file, it'll close the Handle. > Because of laziness, I believe there's no point in my writing the > following: > > > load fn = do handle <- IO.openFile fn IO.ReadMode > > contents <- IO.hGetContents handle > > let xml = XP.xmlParse fn contents > > IO.hClose handle > > return xml > > Is that correct? Yep. Its not neccessary in the usual programming cases to explicitly close the handle. IF you start really hammering the filesystem do you start to care about ensuring files are closed (so you don't hang on to too many FDs). Or if you start mutating files on disk. For these situations there are strict readFiles, or Data.ByteString.readFile -- Don

1 0