December 2003 - Glasgow-haskell-users

RE: Template Haskell and the command line
by Simon Peyton-Jones 18 Dec '03

18 Dec '03

Simon M has persuaded me that -D/-U are really cpp-specific flags. What's to stop you using the environment variables directly? Suppose you had getEnvVar :: String -> Q (Maybe String) which is pretty much what System.getEnv does. Would that do the job? Then you could say DEBUG=yes ghc -fth Foo.hs Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of George Russell | Sent: 02 December 2003 15:32 | To: glasgow-haskell-users(a)haskell.org | Subject: Template Haskell and the command line | | Template Haskell is frightfully good and we want to get rid of cpp and | use it instead, but there's one tiny problem, namely that for cpp it | is possible to define variables on the command line (-DSIMON=MARLOW and so | on) while with Template Haskell it doesn't seem to be. Could there be | some kind of dictionary, like the cpp environment variables, which the | Template Haskell code has access to? | | One obvious way would be to accept the -D/-U arguments, and provide Haskell | functions which look at them. | | Of course one /could/ presumably use System.getArgs and analyse the arguments | to ghc oneself, but that would mean making guesses about the current GHC syntax. | | In the meantime we shall still replace cpp with Template Haskell, but find | another way. Thanks for Template Haskell! | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

"Fail: unknown exception"
by George Russell 18 Dec '03

18 Dec '03

This has to be one of the most irritating ways a program can fall over. Can't the Haskell RTS try just a /little/ harder to help the poor programmer? For example by saying what sort of exception it is, and (if it's a dynamic exception) what type it has?

3 2

RE: ANNOUNCE: GHC version 6.2
by Simon Marlow 17 Dec '03

17 Dec '03

> since GHC version 6.2.the following link is missing: > > http://www.haskell.org/ghc/docs/latest/html/base/index.html > > I asume that I need to change my bookmark to: > > http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Correct - the libraries docs are now build with the latest version of Haddock, which merges all the packages into a single contents/index. Cheers, Simon

1 0

RE: ghc cvs breaks LINE pragma?
by Simon Marlow 16 Dec '03

16 Dec '03

> I use this little script called with > > ghc -pgmF ./drift -F > > ; cat ./drift > #!/bin/ash > if grep -q '{-!' $2; then > echo DrIFT $2 -o $3; > DrIFT $2 -o $3; > else > echo "{-# LINE \"$1\" 0 #-}" >> $3 > cat $2 >> $3; > fi > > however it seems to have stopped working with ghc cvs rather > than 6.01. > it dies with a 'lexical error' on the LINE pragmas generated by the > script and DrIFT. > any idea what the problem is? > John LINE pragmas are supposed to have the line number first. As far as I can tell, it's always been like this. GHC 6.0 was a bit more relaxed about accepting LINE pragmas, although I think that was an accident (looking at the code it doesn't look like the pragma would be interpreted properly, but it might be skipped over). Cheers, Simon

1 0

RE: ghc warnings messed up in 6.01
by Simon Peyton-Jones 16 Dec '03

16 Dec '03

Done, I believe. It'll be in the next release (6.3/6.4). Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Mike Gunter | Sent: 07 December 2003 16:50 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: ghc warnings messed up in 6.01 | | | Simon seems to have agreed that The Right Thing is to treat bindings | with names beginning with an underscore as if they are used w.r.t. to | the bindings they use (they're already treated as used w.r.t. warnings | for themselves.) With this enhancement (and the other warning fixes | apparently already in HEAD), you should be able to change "ds" to | "_ds" and get no warnings. | | BTW (here's the real point of my message :-)), is this enchancement | planned? For when? Thanks. | | mike | | | > has anyone else noticed that the warnings generated by ghc appear to | > have become quite incorrect in many cases? | > | > in particular, the 'defined but not used' warning is generated | > spuriously a lot. almost as if it is being checked after dead code | > elimination and desugaring of some sort.. | > | > here is an example which touches all the reproducable bugs I have found. | > | >> module Main(main) where | >> import List(nub) | >> import Monad() | >> | >> as = repeat 'a' | >> bs = repeat 'b' | >> ds = nub as | >> | >> cs = [(a,b) | a <- as | b <- bs] | >> | >> main = print $ take 10 cs | > | > | > ;ghc -W -fglasgow-exts Foo.hs | > | > Foo.hs:1: | > Warning: Module `List' is imported, but nothing from it is used | > (except perhaps instances visible in `List') | > | > Foo.hs:1: | > Warning: Module `Monad' is imported, but nothing from it is used | > (except perhaps instances visible in `Monad') | > | > Foo.hs:7: Warning: Defined but not used: ds | > | > Foo.hs:9: Warning: Defined but not used: b | > | > Foo.hs:9: Warning: Defined but not used: a | > | > | > notice: | > | > 1) it claims nothing is used by List, when 'nub' definatly is being | > used. (technically true, since ds is not used, but this warning is more | > confusing than anything. my first inclination is to delete the import | > line, causing the program to fail to compile, the only fix seems to be | > to track down the root by hand) | > | > 2) it claims Monad is unused, when I specifically imported it with () | > meaning I don't want any names from it. (i.e., I just want instances) | > | > 3) defined but not used 'ds': yay! the only valid warning. | > | > 4,5) variables bound in parallel list comprehensions always seem to | > generate warnings. | > | > | > AFAIK, none of these were problems in earlier versions of ghc, they are | > quite anoying as they obscure valid warnings. my guess is some | > desugarings and warning passes were accidentally switched around.. | > problem 1 is particularly bad, since a single unused toplevel could | > cascade to generating a ton of warnings, all of which must be sorted | > through to find the actual cause. the others are just anoying as there | > doesn't seem to be a workaround short of disabling warnings. | > | > John | > -- | > ------------------------------------------------------------------------ --- | > John Meacham - California Institute of Technology, Alum. - john(a)foo.net | > ------------------------------------------------------------------------ --- | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: To show or not to show french accents
by Simon Marlow 16 Dec '03

16 Dec '03

> The following haskell program : > > --<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > module Main where > > accentLetters :: String > accentLetters = "éàô" > > main :: IO () > main = do putStr (show accentLetters) > -->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > after being compiled will give the result : > > "\233\224\244" > > But, exactly the same program, without the "show" function > will give the result: > > éàô > > Is there some way to have "show" show all the printable > characters, even those > represented by a value greater than the US-ASCII 7 bits (127) ? This is the correct result, according to the Haskell 98 report (see the definition of Char.showLitChar). However, arguably the Haskell 98 behaviour is wrong, since there are lots of printable Unicode characters >127. We don't propose to do anything here. Cheers, Simon

1 0

RE: incompatible signatur syntax within instance definition
by Simon Peyton-Jones 15 Dec '03

15 Dec '03

| This is legal in Haskell 98, because the `a' in the inner declaration is | implicitly universally quantified. But if the scope of the outer type | variable `a' extends over the inner type declaration, then the inner `a' | will not be locally universally quantified, and the call to `bar' will | be a type error, because the `a' in the head of the instance declaration | will in general be different than `Int'. | ... | | P.S. I note that ghc 5.02.2 enables this extension always, regardless | of the setting of -fglasgow-exts. That seems like a bug to me. And indeed, GHC 6.0 fixes this bug: no scoped type variables without -fglagow-exts. Simon

1 0

ghc cvs breaks LINE pragma?
by John Meacham 14 Dec '03

14 Dec '03

I use this little script called with ghc -pgmF ./drift -F ; cat ./drift #!/bin/ash if grep -q '{-!' $2; then echo DrIFT $2 -o $3; DrIFT $2 -o $3; else echo "{-# LINE \"$1\" 0 #-}" >> $3 cat $2 >> $3; fi however it seems to have stopped working with ghc cvs rather than 6.01. it dies with a 'lexical error' on the LINE pragmas generated by the script and DrIFT. any idea what the problem is? John PS. on another tangent (although this is is probably a library issue), I tried modifying my code to use the new Data.Generics rather than Strafunski, and found that Data could not be derived because instances for a lot of built in classes don't exist and it is unclear how to write them by hand. is it possible to retroactivly add a 'deriving' clause to something that was declared in another unmodifyable module? or can we make sure that all predefined (and library) types derive Data? -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

1 1

forkProcess type changed?
by George Russell 11 Dec '03

11 Dec '03

For the development snapshot 6.3.20031201, System.Posix.forkProcess has the type IO () -> IO System.Posix.Types.ProcessID. In 6.0.1 it has type IO () -> IO (Maybe System.Posix.Types.ProcessID). Is this change intentional, and if so how are you supposed to test after the fork if this is the parent or child process?

3 2

RE: forkProcess type changed?
by Simon Marlow 11 Dec '03

11 Dec '03

> For the development snapshot 6.3.20031201, System.Posix.forkProcess > has the type IO () -> IO System.Posix.Types.ProcessID. In 6.0.1 > it has type IO () -> IO (Maybe System.Posix.Types.ProcessID). Is > this change intentional, and if so how are you supposed to test > after the fork if this is the parent or child process? Yes, this is intentional. It turned out to be far too difficult to implement forkProcess as it was previously defined (problems with what happens when the current thread returns in the child process was one difficulty, IIRC). The previous implementation had some serious bugs. See the docs for the new version here: http://www.haskell.org/ghc/docs/6.2/html/libraries/unix/System.Posix.Pro cess.html#v%3AforkProcess Cheers, Simon

1 0