August 2002 - Glasgow-haskell-users

Hardware STG?
by MR K P SCHUPKE 21 Aug '02

21 Aug '02

Hi, I am looking into starting a project on special hardware to run haskell - (or perhapse any lazy functional hardware)... If I go ahead the project will result in an open VHDL implementation. I would like to ask a couple of questions. Is there any point in doing this as the STG-machine is designed to make running haskell efficient on standard hardware? is TCode and the byte code used by GHCi the same? finally, does anyone know of any implementations that have already been attempted, and how successful were they? Any general comments on how worthwhile this might be? Regards, Keean Schupke Department of Electrical & Electronic Engineering, Imperial College London.

1 0

genprimopcode segfaulting in Gentoo ebuild
by Sven Moritz Hallberg 21 Aug '02

21 Aug '02

Hi, I have just received a bug report for the Gentoo Linux ebuild of GHC 5.04 whose cause I cannot find. Recall that Gentoo builds all packages from sources. The build processes stops when genprimopcode segfaults during the last stage of the build (GHC 5.04 building itself). Anyone interested please look at http://bugs.gentoo.org/show_bug.cgi?id=6352 for the complete Bugzilla entry which has all available details, including an strace of the segfaulting genprimopcode. Thanks, Sven Moritz Hallberg

1 0

RE: redirecting stdin/stdout
by Simon Marlow 21 Aug '02

21 Aug '02

> I would like to be able to semi-permanently redirect stdout > particularly. That is, say something like: > > main = do > h <- openFile "myoutput" WriteMode > setStdOut h > ..crux of the program.. > hClose h > > where any call which uses stdout either explicitly or > implicitly (through > putStr and the like) is redirecto to h. > > I didn't see anything of this sort in either the std libs IO or in the > GHC.IO/IOBase modules...would such a thingbe possible? Yes, it is entirely possible to do this, and in fact we used to have such a thing (withStdout, withStderr) which got dropped when I re-implemented the I/O system. It's not immediately clear what the interface should be, though. If we have setStdout :: Handle -> IO () what happens to the original handle? It's unfortunately not possible to make stdout then be equal (in the == sense) to the handle passed in, although stdout would from then on behave like the other handle. Since in Haskell it is illegal to have two handles that refer to the same file, without the handles being equal, the original handle would have to be closed. Also there's a slight complication caused by GHC's representation of handles. Some handles have two independent "sides" to cope with the fact that a read/write stream (eg. a socket) needs two separate buffers. It wouldn't be possible to do setStdout with a stream-type Handle (or perhaps you just get the output side of the stream Handle). Cheers, Simon

3 2

redirecting stdin/stdout
by Hal Daume III 20 Aug '02

20 Aug '02

I would like to be able to semi-permanently redirect stdout particularly. That is, say something like: main = do h <- openFile "myoutput" WriteMode setStdOut h ..crux of the program.. hClose h where any call which uses stdout either explicitly or implicitly (through putStr and the like) is redirecto to h. I didn't see anything of this sort in either the std libs IO or in the GHC.IO/IOBase modules...would such a thingbe possible? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

Re: Question about error message
by Paulo Sequeira 20 Aug '02

20 Aug '02

Ok, you got me. My wording was not careful, so I must rectify. If you try let xyz = do getLine in do p <- xyz; putStr p you'll see that in xyz I'm not really discarding the string read (you caught it later in p). Definitively, Alastair's explanation is more correct than mine and it didn't lead you to a misunderstanding. You must understand that do notation is mostly syntactic sugar. It is more familiar to write do p <- getLine; putStr p than to write getLine >>= (\ p -> putStr p) What I really mean by "discarding" was that, if you write do getLine; stmt you would simply won't have at hand the line read in stmt because the value was not bound to any variable. Note that the previous line is equivalent to getLine >> do stmt or, by the definition of >> getLine >>= (\ _ -> do stmt) See it? Also, note that when you write do getLine in GHCi, it is GHCi who is "discarding" the string. (mmm, would this last statement be also misleading?) Hope I'm now explaining myself better. Paulo. ----- Original Message ----- From: Seth Kurtzberg <seth(a)cql.com> To: Paulo Sequeira <otro_paulo(a)hotmail.com> Sent: Saturday, August 17, 2002 7:25 PM Subject: Re: Question about error message > Paulo, and also Alastair, > > Thanks for the responses. And, from a practical perspective, Paulo's > workaround is interesting (and also works). But ... > > Wait a minute. The type (according to GHCI) of both: > > xyz = do getLine > > and > > abc = do p <- getLine > return p > > is IO String. And, in fact, both expressions indeed return the String part of > the IO String. So (I'm playing devil's advocate here) you are asserting that > it is correct for one entity of type IO String to provoke different behavior > than another entity of type IO String. All "IO String"s are not created > equal. > > I don't see, fundamentally, how it violates referential integrity or any other > functional programming principle to stick a value somewhere and not use it. > It might not be very intelligent, or useful, but that is irrelevant from the > theoretical perspective. > > And, the restriction has a negative impact on code reuse. I shouldn't need to > define both "abc" and "xyz" in the above example, which do the same thing, > merely because sometimes I want the result and other times I don't. > > On Saturday 17 August 2002 16:14, you wrote: > > Perhaps it will help if you recall the meaning of the do notation, > > according to the Haskell98 Report. > > > > do {e} = e > > do {e;stmts} = e >> do {stmts} > > do {p <- e; stmts} = > > let > > ok p = do {stmts} > > ok _ = fail "..." > > in e >>= ok > > do {let decls; stmts} = let decls in do {stmts} > > > > > > Note that "do p <-e" only has meaning when is followed by something else > > (e.g. an expresion). One way to explain it is that it only makes sense to > > introduce "p" to use it later (e.g. you are reading a string and binding it > > to "p" to parse it later). If you are only interested in the side effects > > of "getLine", you should write: > > > > main = do getLine > > > > This will effectively read a line and discard it afterwards. Try it. > > > > Paulo. > > > > ----- Original Message ----- > > From: Seth Kurtzberg <seth(a)cql.com> > > To: <glasgow-haskell-users(a)haskell.org> > > Sent: Saturday, August 17, 2002 2:23 PM > > Subject: Question about error message > > > > > Hello, all > > > > > > There is an error message that I get from GHCI that I do not understand. > > > Usually it is caused by a syntax error or an indentation error, but I > > > have occasionally seen it in other contexts and I'd like to understand > > > what it > > > > is > > > > > trying to tell me. > > > > > > The message is that the last statement in a do construct must be an > > > > expression > > > > > (exact text below). > > > > > > I believe this occurs when the last statement in the do construct has a > > > > type > > > > > other than "IO ()". The documentation (or perhaps Simon Thompson's or > > > > Paul > > > > > Hudak's book; they get jumbled together in my mind) states that all > > > statements in a do construct have type "IO ()"; but this is clearly not > > > correct, as in: > > > > > > do line <- getLine > > > putStrLn line > > > > > > where the first statement has type IO String. > > > > > > Here is an example. This code is useless but it is not obvious to me why > > > > it > > > > > is incorrect: > > > > > > main = do line <- getLine > > > > > > producing the error: > > > > > > <interactive>:1: The last statement in a 'do' construct must be an > > > > expression > > > > > (This also limits the ability to enter monadic programming to the > > > interpreter.) > > > > > > TIA, > > > > > > -- > > > Seth Kurtzberg > > > M. I. S. Corp > > > seth(a)cql.com > > > 1-480-661-1849 (GMT-7) > > > > > > _______________________________________________ > > > Glasgow-haskell-users mailing list > > > Glasgow-haskell-users(a)haskell.org > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- > Seth Kurtzberg > M. I. S. Corp > seth(a)cql.com > 1-480-661-1849 (GMT-7) >

3 2

RE: weird floating point exception with -Rghc-timing
by Simon Marlow 19 Aug '02

19 Aug '02

> It seems that if compilation is not required, or if > compilation is very > fast, ghc -Rghc-timing will throw up a Floating point exception: > > [hdaume@hal3 timing]$ ls > Timing.hs > [hdaume@hal3 timing]$ cat Timing.hs > module Timing where > > timing = undefined > > [hdaume@hal3 timing]$ ghc -Rghc-timing Timing.hs -c > <<ghc: 9358352 bytes, Floating point exception This is a divide-by-zero bug in the code that generates the stats, which I think I've fixed. You must have some custom heap settings that are triggering this though: is your GHC_RTS environment variable set to anything? Cheers, Simon

1 0

weird floating point exception with -Rghc-timing
by Hal Daume III 19 Aug '02

19 Aug '02

It seems that if compilation is not required, or if compilation is very fast, ghc -Rghc-timing will throw up a Floating point exception: [hdaume@hal3 timing]$ ls Timing.hs [hdaume@hal3 timing]$ cat Timing.hs module Timing where timing = undefined [hdaume@hal3 timing]$ ghc -Rghc-timing Timing.hs -c <<ghc: 9358352 bytes, Floating point exception [hdaume@hal3 timing]$ ls Timing.hi Timing.hs Timing.o [hdaume@hal3 timing]$ rm *.hi *.o [hdaume@hal3 timing]$ ghc Timing.hs -c [hdaume@hal3 timing]$ ls Timing.hi Timing.hs Timing.o [hdaume@hal3 timing]$ Am I right or is something else going on here...? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

RE: ghc 5.04 -- make -prof -auto-all under WinNT
by Simon Marlow 19 Aug '02

19 Aug '02

> I tried to compile the following little program (hallo.hs) > with ghc-5.04 --make -prof -auto: We have some problems with profiling on Windows in 5.04. At least one bug has been tracked down and fixed, and we'll try to make sure that profiling is working properly for 5.04.1. Sorry I can't offer any workarounds, other than to try using a Unix box of some description to do your profiling on. Cheers, Simon

1 0

Question about error message
by Seth Kurtzberg 17 Aug '02

17 Aug '02

Hello, all There is an error message that I get from GHCI that I do not understand. Usually it is caused by a syntax error or an indentation error, but I have occasionally seen it in other contexts and I'd like to understand what it is trying to tell me. The message is that the last statement in a do construct must be an expression (exact text below). I believe this occurs when the last statement in the do construct has a type other than "IO ()". The documentation (or perhaps Simon Thompson's or Paul Hudak's book; they get jumbled together in my mind) states that all statements in a do construct have type "IO ()"; but this is clearly not correct, as in: do line <- getLine putStrLn line where the first statement has type IO String. Here is an example. This code is useless but it is not obvious to me why it is incorrect: main = do line <- getLine producing the error: <interactive>:1: The last statement in a 'do' construct must be an expression (This also limits the ability to enter monadic programming to the interpreter.) TIA, -- Seth Kurtzberg M. I. S. Corp seth(a)cql.com 1-480-661-1849 (GMT-7)

3 2

RE: (not) catching ^C in ghc-built application
by Simon Marlow 16 Aug '02

16 Aug '02

> > I have a program, written in a mixture of Haskell and C, in > which the > > C part is supposed to handle a ^C interrupt, accomplished > through the > > usual signal() call. But when it is compiled by ghc, for > some reason > > the ghc RTS appears to trap the interrupt itself, and halts the > > program with the message > > prog: interrupted > > instead of allowing the newly installed C signal handler to run. > > I finally found the cause of this. The ghc RTS has a global variable > `interrupted', which is set by its interrupt handler, and tested by > various other parts of the scheduler. > > Guess what - my C routines also have a global variable called > `interrupted', and my own ^C interrupt handler was also setting > this variable. D'oh. If I change the name of my global variable, > then everything works as it ought to. > > I know it's a pain for you, but can I file this as a bug report > in ghc? Stealing simple and obvious global identifiers from the > user's namespace is rather dangerous, and even more so when it is > undocumented. These global "common" variables are a pain in the neck. There are 44 of these in GHC's RTS - we should really at the least initialise them so that you'll get a conflict if you define a global with the same name in your own code. Thanks for the report. Cheers, Simon

1 0