- Glasgow-haskell-users

Re: To show or not to show french accents
by francis.girard＠free.fr 19 Dec '03

19 Dec '03

Good afternoon, Well, I think there should probably be some internationalisation mechanism that tells the "show" function (to name one), according to some configuration, how to interpret a byte as a character. Frankly, I see no good reason why we should be satisfied we the dinosaurus 7 bits except perhaps because 7 bits is sufficient for english. I am talking about respect for non english speaking people. But if nobody cares ... Cheers, Francis Girard LE CONQUET France Selon Max Kirillov <max630(a)mail.ru>: > On Tue, Dec 16, 2003 at 07:49:26AM +0100, francis.girard(a)free.fr wrote: > > Good morning, > > > > 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) ? > > > > The specific octet may be printable character or not depending on your > charset. For instance, your letters are printable in koi8-r (showing > upper Russian I YU T), but not in cp866 (al least recode cp866..koi8-r > fails on them). > > The "show" function represents your over-127 bytes in portable and > readable (by read) way and, I think, it does right. > > -- > Max > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

4 5

RE: Installation problem on suse 9.0.
by Simon Marlow 18 Dec '03

18 Dec '03

[ moved to glasgow-haskell-users(a)haskell.org ] > i have running ghc on suse 7.3, but i can't install it on > suse 9.0. the > next error is raising during the HC files compilation: > > -------------------------------------------- > ... > CTypes.hc:55265: warning: (near initialization for > `CTypes_tpl890_closure.payload') CTypes.hc:55297: warning: excess > elements in array initializer > CTypes.hc:55297: warning: (near initialization for > `CTypes_tpl891_closure.payload') CTypes.hc:55324: warning: excess > elements in array initializer > CTypes.hc:55324: warning: (near initialization for > `CTypes_zdfReadCChar_closure.payload') CTypes.hc:55324: > warning: excess > elements in array initializer > CTypes.hc:55324: warning: (near initialization for > `CTypes_zdfReadCChar_closure.payload') CTypes.hc:55324: > warning: excess > elements in array initializer > CTypes.hc:55324: warning: (near initialization for > `CTypes_zdfReadCChar_closure.payload') Prologue junk?: czvw_ret: > movl $0, 16(%esp) > movl $0, 20(%esp) > movl $0, 8(%esp) > movl $0, 12(%esp) > > gmake[2]: *** [CTypes.o] Error 255 > gmake[1]: *** [all] Error 1 > gmake: *** [all] Error 1 Which GHC version are you compiling? Which GHC vesrion are you using to compile it? It might be related to a newer version of gcc: what version is installed on your system? Cheers, Simon

1 0

Running a "final" finaliser
by Adrian Hey 18 Dec '03

18 Dec '03

Hello, I hope this question isn't too stupid, but I can't find any obvious way to do this from reading the ghc docs. What I want to do is call a final foreign function (a library shutdown routine) when Haskell terminates, but after all ForeignPtr finalisers have been run. I suppose I could implement some kind of finaliser counter so the last finalizer could tell it was the last finaliser and call the shutdown routine, but this seems a little awkward, especially as these days the FFI requires finalisers to be foreign functions. The other possibility that occurs to me is that I call performGC at the very end of the program, immediately before calling the library shutdown routine. But I'm not too sure whether that will guarantee that all finalizers have been run even if there are no live references to foreign objects at that point. (Using GC as described in the "non-stop Haskell" paper it seems possible that finalisers won't be run immediately in response to performGC.) Is there a better way? Thanks -- Adrian Hey

1 0

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