February 2003 - Glasgow-haskell-users

RE: effect of order of function arguments
by Josef Svenningsson 19 Feb '03

19 Feb '03

[moved over to glasgow-haskell-users] On Wed, 19 Feb 2003, Simon Peyton-Jones wrote: > | GHC used to have an optimisation for static argument like this. It > would > | turn both of the above programs into a similar form using a local > | recursive function: > | > | interp y xs = interpaux xs > | where interpaux [] = [] > | interpaux (x:[]) = x:[] > | interpaux (x:xs) = x:y:interpaux xs > | > | GHC doesn't do this anymore. The reason for this is unknown to me. > > It turned out to be a very minor effect (1-2% of execution time) and > hard to tune; with lots of parameters, it's best to make a local > function, with just a few it's best to pass the parameters round. > I see. I'm a little surprised though. I thought that performing SAT (static argument transformation) would make GHC much keener on inlining the function. My expectation was that there would be some gain from that. Just as a comment I can add that in my paper "Shortcut fusion for accumulating parameters & zip-like functions" in last year's ICFP I performed SAT by hand on the definition of unfoldr and foldl' in order to make all the inlining happen in the way I wanted. Without this I would either have to rely on the compiler performing SAT or there would be no fusion. My gut feeling (which ofcourse can be wrong) is that SAT can play an important role when transforming programs. /Josef

1 0

Re: awaitEval in Concurrent Haskell
by C.Reinke 19 Feb '03

19 Feb '03

> Actually a mild variant of Claus's proposal seems to work out > quite well. Another way to avoid the problems with types is > to use a multi-parameter type class. Little example attached. Glad to be of help. The need to shadow the data types is a bit annoying, but then the whole generic bit would preferably be generated anyway. Template Haskell to the rescue, or Drift?-) > .. the availability of data would only be detected if the demand > that prompted its evaluation was in the context of the > assertion-tagged expression. Yes? Yes - same issues with sharing as in Hood. You could tag the expression before sharing, though. And in your application, you might actually prefer to have that fine distinction: just because someone else has evaluated a shared expression far enough to allow your assertion to be evaluated, that doesn't mean that this assertion will be relevant to the program run. There is still something I don't understand about your specification: the assertions take on a post-mortem character - by the time the assertion fails, the main thread might have run into trouble already (after all, its evaluation drives the assertion). So while this would work, let l = "" print $ length $ assert "non-empty l" (not . null) l this might not be a good idea: let l = "" print $ head $ assert "non-empty l" (not . null) l At best, you get both the main-thread error and the assertion-thread failure message. That's why I was asking what you intend to do with the assertions. Cheers, Claus

2 1

RE: The semantics of Core?
by Simon Peyton-Jones 19 Feb '03

19 Feb '03

I seriously doubt that you want to produce all the .hcr files for the entire set of GHC's libraries. They'll be pretty big. But if you do, just get a GHC build tree, make your GHC, get into the libraries tree (fptools/libraries) and type make EXTRA_HC_OPTS=-fext-core That'll build the libraries and dump an .hcr file for each module Simon | -----Original Message----- | From: Martin Sjögren [mailto:md9ms@mdstud.chalmers.se] | Sent: 18 February 2003 09:55 | To: glasgow-haskell-users(a)haskell.org | Subject: RE: The semantics of Core? | | tis 2003-02-18 klockan 09.49 skrev Simon Peyton-Jones: | > I don't know of any separate description of the semantics of Core, but it's just the | lambda calculus with let, letrec and case. There's plenty of code that works over Core | in GHC itself, but no separate libraries. There is a library to parse the stuff that ghc - | fext-core spits out, though. | | I was more interested in the strictness properties. The way I understood | it, Core case is strict? | | I looked at utils/ext-core and now I'm stuck at producing all the .hcr | files needed. I just can't think of a good way of getting .hcr files | from all modules that Prelude imports. I've tried tricks with -fno-code | and tricks with --make -no-hs-main but to no avail so far. With | | ghc --make -fglasgow-exts -fext-core -no-hs-main Prelude.hs | | I get | | GHC/Base.lhs:84: parse error on input `#' | | If I pass -cpp too, I get | | GHC/Base.lhs:96: | failed to load interface for `GHC.Err': | Bad interface file: GHC/Err.hi-boot | does not exist | Action: openFile | Reason: No such file or directory | File: GHC/Err.hi-boot | | I'm confused. All manner of help appreciated. :) | | | /Martin

1 0

Re: The semantics of Core?
by Kirsten Chevalier 18 Feb '03

18 Feb '03

On Tue, Feb 18, 2003 at 12:01:02PM -0500, glasgow-haskell-users-request(a)haskell.org wrote: > I'm also looking for actual code for working with Core. :) The > Language.Haskell.* stuff gives me a very high-level representation of > Haskell source, and I'd rather work with something simple, like Core. I > *suppose* I could use ghc -fvia-ext or helium -C or something like that, > and then parse the file it spits out, but it feels like a long way to go > when there should be shortcuts available. Another way is to rip out the > code from ghc or helium that does this, but that's not so nice either :( > There is a parser, typechecker, interpreter, and printer for Core in ghc/utils/ext-core in the fptools distribution. The typechecker and interpreter don't work on Core produced by the latest version of GHC, but the parser and printer should still work OK. It's a lot easier than linking your code with code from GHC! -- Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt

1 0

permissions on ghc Windows installer?
by Malcolm Wallace 18 Feb '03

18 Feb '03

I have been attempting to solve some outstanding problems with building hmake, nhc98, and hat, using ghc under Windows. I don't have a Windows machine of my own, but our Dept has some public-access Windows 2000 Pro machines I can use. However, when I try to use the ghc .msi automatic installer package, it reports that I do not have sufficient privileges to install ghc in my own temporary disk area. Apparently it needs administrator privileges, which I do not have (and will not be able to acquire). Are administrator privileges really required? I notice that the installer for Cygwin (i.e. not ghc) explicitly allows you to choose whether to install for all users or "just for me". Would it be difficult to allow the same choice in the ghc installer? Regards, Malcolm

2 1

BU FIRSATTAN RARARLANIN.
by MARAMARA Erotik Market 18 Feb '03

18 Feb '03

DIKKAT VIDEO CD : Iddia ediyoruz.. Hic bir yerden temin edemeyeceginiz ses ve g�runtu kalitesi ile yuzlerce porno video CD. arSivimiz yenilenmistir. istemis oldugunuz video CD.ler bire bir yollanir kesinlikle isteginiz harici alakasiz baSka video CD.ler yollanmaz. Anal. Oral. Vajinal. Grup. Zenci. FethiS. Ayak fethiS. Gay. Zenci gay. Trans. Transexual. Lezbiyen ve daha bircok ceSit .... <http://www.erotik.sites.cc/> ZENGIN URUN CESITLERIMIZ : Sisme Bebekler ..... (Erkek & Bayan) Kesinlikle size hayir demeyecek. Vibrat�rler ........ Istediginiz boy ve ebatlarda (Vajinal/Anal/catal.Pilli.Motorlu.TitreSimli) Suni Vajinalar ..... Asla gerceginden ayirt edemeyeceksiniz (Gercek ten hassasiyetinde) Reailistik Penisler. Gercek ten hassasiyetinde ve dokusunda (Vantuzlu/Deri kemer kilotlu) Vakum Pompalari .... Ereksiyonu kolaylastirici ve duzenli kullanimlarda peniste irilesme saglar. Geciktiriciler ..... Erken boSalmayi dert etmeyin (Sprey ceSitleri/Kremler) Kremler ............ Anal ve Vajinal iliSkilerde kullanabileceginiz kayganlaStirici krem ceSitleri Uyandiricilar ...... Cinsel istek uyandirici haplar ve damlalar. Yapmaniz gereken tek Sey <http://www.erotik.sites.cc/> TIKLAMAK .. NOT : BU MAIL REKLAM AMAcLI OLUP HIcBIR SEKILDE TARAFIMIZDA KAYDINIZ BULUNMAMAKTADIR. ILGI ALANINIZIN DISINDA ISE EGER LUTFEN DIKKATE ALMAYINIZ TESEKKURLER..

1 0

RE: Question about compiling CGIs with Ghc
by Simon Marlow 18 Feb '03

18 Feb '03

> http://www.haskell.org/ghc/docs/latest/html/network/Network.CGI.html > > This make me curious, and the following just made me curiouser... > > Forbidden > You don't have permission to access > /ghc/docs/latest/html/network/Network.CGI.html on this server. *Sigh* That's because Apache thinks it's a CGI script. I just checked the Apache documentation, which doesn't suggest any workarounds apart from renaming the file: http://httpd.apache.org/docs/mod/mod_mime.html#multipleext I've renamed the file, and the links to it, for now: http://www.haskell.org/ghc/docs/latest/html/network/Network._CGI.html Cheers, Simon

1 0

RE: Yet another weakly defined bug report
by Simon Marlow 18 Feb '03

18 Feb '03

> The following code runs out of file handles, so I am seeking > enlightenment as to why. > > > -- | add data from a file to the histogram > > addFile :: FiniteMap String Int -> String -> IO (FiniteMap > String Int) > > addFile fm name = do > > x <- readFile name > > return (addHist fm x) > > > > -- | add data from all files in a directory to the histogram > > addDir :: FiniteMap String Int -> String -> IO (FiniteMap > String Int) > > addDir fm dir = do > > dc <- getDirectoryContents dir > > fs <- filterM doesFileExist (map ((dir++"/")++) dc) > > foldM addFile fm fs > > Running addDir on a directory with few hundred files trigs it. > Shouldn't all of each file's contents be consumed by each addFile, and > thus the handle be released? It's not possible to tell from this code whether the readFiles will be fully evaluated or not: it depends on how much evaluation addHist does, and to what extend the result FiniteMap is demanded, amongst other things. These things are always tricky to understand, which is why I recommend not using lazy I/O. File reading is not a pure operation: running out of file descriptors is a good counter-example. Cheers, Simon

4 7

RE: The semantics of Core?
by Simon Peyton-Jones 18 Feb '03

18 Feb '03

I don't know of any separate description of the semantics of Core, but it's just the lambda calculus with let, letrec and case. There's plenty of code that works over Core in GHC itself, but no separate libraries. There is a library to parse the stuff that ghc -fext-core spits out, though. Kirsten Chevalier and Tobias Gedell have experience of using this route, and may be able to help, depending on your purpose. Contributing well-engineered Core-manipulating libraries would be a Good Thing. Simon | -----Original Message----- | From: Martin Sjögren [mailto:md9ms@mdstud.chalmers.se] | Sent: 18 February 2003 08:18 | To: glasgow-haskell-users(a)haskell.org | Subject: The semantics of Core? | | Hello | | I'm looking for a paper or some other documentation on the exact | semantics of Core. I've read the paper about the concrete syntax, and it | briefly mentions the abstract syntax and something about the case | expression, but not a lot. Unless I missed something? | | I'm also looking for actual code for working with Core. :) The | Language.Haskell.* stuff gives me a very high-level representation of | Haskell source, and I'd rather work with something simple, like Core. I | *suppose* I could use ghc -fvia-ext or helium -C or something like that, | and then parse the file it spits out, but it feels like a long way to go | when there should be shortcuts available. Another way is to rip out the | code from ghc or helium that does this, but that's not so nice either :( | | Any suggestions? | | | /Martin

2 1

The semantics of Core?
by Martin Sjögren 18 Feb '03

18 Feb '03

Hello I'm looking for a paper or some other documentation on the exact semantics of Core. I've read the paper about the concrete syntax, and it briefly mentions the abstract syntax and something about the case expression, but not a lot. Unless I missed something? I'm also looking for actual code for working with Core. :) The Language.Haskell.* stuff gives me a very high-level representation of Haskell source, and I'd rather work with something simple, like Core. I *suppose* I could use ghc -fvia-ext or helium -C or something like that, and then parse the file it spits out, but it feels like a long way to go when there should be shortcuts available. Another way is to rip out the code from ghc or helium that does this, but that's not so nice either :( Any suggestions? /Martin

1 0