June 2005 - Glasgow-haskell-users

Documentation for GHC primops
by Simon Peyton-Jones 16 Jul '05

16 Jul '05

Dear GHC users This message is a request for help with a well-contained task that will improve GHC's Haddock documentation. GHC provides lots of primitive operations. They are described in a single ASCII files primpos.txt.pp; the description in that file gives types and English-language descriptions, as well as some other GHC-ish information. This description file is chomped up by a pre-processor (genprimopcode), which produces either (a) Haskell source code for data types describing the primops [these modules become part of GHC itself), or (b) Latex stuff which can be part of a document. You can see the output in Section 4.4 of the External Core document (http://www.haskell.org/ghc/docs/papers/core.ps.gz) However, there's no Haddock document describing all these primops!! Although they are all available through the module GHC.Exts, the Haddock documentation for GHC.Exts says nothing at all about them. http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC.Exts.html Reason: there is no Haskell source code for GHC.Prim, the pseudo-module that exports all the primops. What we want is to generate GHC.Prim.hs from primops.txt.pp. This .hs file would not be fed to GHC; rather it'd just be there so that Haddock could see it. For example: module GHC.Prim( ...list all primops... ) where (+#) :: Int# -> Int# -> Int# --| Adds two unboxed Ints ...etc... you get the idea. No Haskell code, only type signatures. Would someone cares to write this new backend to "genprimopcode". The latter is a Haskell program that can parse primops.txt.pp, and already has two back ends (a) and (b) above. What we want is to add (c) generate Haskell that Haddock can understand. Note that the documentation itself is already written -- it's in primpos.txt.pp. That's what's so tantalising. All that we need is to mangle it into Haddock. Any volunteers? It doesn't involve touching GHC itself. "gemprimopcode" is a completely standalone Haskell program, currently some 730 lines long. Simon

4 3

RE: Re[2]: ANNOUNCE: GHC survey results
by Konovalov, Vadim 30 Jun '05

30 Jun '05

> btw, in Pugs sources > (http://search.cpan.org/CPAN/authors/id/A/AU/AUTRIJUS/Perl6-Pugs-6.2.7.tar.g z) > there is Unicode.hs module wich can classify and convert full range of > Unicode symbols under any OS. i don't understand - is this module > already included in GHC 6.5? if not, it would be good addition that file reads: -- Based on the GHC.Unicode library, Copyright 2005, Dimitry Golubovsky. -- See GHC's LICENSE file for the full license text. That said, it is part of GHC?

1 0

RE: resolving Show instance
by Simon Peyton-Jones 30 Jun '05

30 Jun '05

path gets the inferred type path :: forall a. [a] This polymorphic type is instantiated once when it is passed to 'subterm' and again, quite separately, when it is passed to 'shows'. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 30 June 2005 11:58 | To: glasgow-haskell-users(a)haskell.org | Subject: resolving Show instance | | Who knows, please, why does there happen, now and then, the effects | of the following kind? | | The ghc-6-4-branch-June-15-2005 compiler cannot resolve the Show | instances in the following program | (using overlapping and `undecidable' instances): | | ------------------------------------------- | import Dumatel | main = putStr (shows path $ shows (subterm path t) "\n") | where | th = bool defaultVariableWeight defaultInitialOpId weightDecls lpo | where | weightDecls = [] | | t = parseSingleOrBreak th "bool" "x & (not x)" :: Term | | path = [] -- :: SubtermPath | ------------------------------------------- | | | It cannot choose the Show instance for path = []. | But | 1) the above `putStr' line contains a subexpression | shows (subterm path t) "\n", | | 2) the imported modules contain the declarations | | subterm :: SubtermPath -> Term -> Term | ... | type SubtermPath = [Integer] | | Hence, it should derive the type for path : [Integer]. | | Also setting path = [1] | or path = [] :: SubtermPath | instead of the line | path = [] | satisfies the compiler. | | This is not a problem for me to guess to add `:: SubtermPath'. | This is a question of curiosity. | The compiler sees to which function `path' is fed to, and sees the | argument types of this function. Hence, why does not it find the | type for `path' ? | | I am sure that much simpler example is possible | (the imported universe is complex), maybe even without overlaps. | But maybe, people can explain the effect right for this example as | it is? | The report is | | ------------------------------------------ | Overlapping instances for Show [a] | arising from use of `shows' at GHCBug.hs:5:15-19 | Matching instances: | Imported from GHC.Show: instance (Show a) => Show [a] | Imported from Prelude3: instance Show [Equation] | Imported from Prelude3: instance Show [Term] | (The choice depends on the instantiation of `a' | Use -fallow-incoherent-instances to use the first choice above) | In the first argument of `($)', namely `shows path' | In the first argument of `putStr', namely | `((shows path) $ (shows (subterm path t) "\n"))' | In the definition of `main': | main = putStr ((shows path) $ (shows (subterm path t) "\n")) | where | path = [] | th = bool defaultVariableWeight defaultInitialOpId weightDecls lpo | where | weightDecls = [] | t = parseSingleOrBreak th "bool" "x & (not x)" :: Term | -------------------------------------------------------- | | | Thank you in advance for explanations. | | ----------------- | Serge Mechveliani | mechvel(a)botik.ru | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

resolving Show instance
by Serge D. Mechveliani 30 Jun '05

30 Jun '05

Who knows, please, why does there happen, now and then, the effects of the following kind? The ghc-6-4-branch-June-15-2005 compiler cannot resolve the Show instances in the following program (using overlapping and `undecidable' instances): ------------------------------------------- import Dumatel main = putStr (shows path $ shows (subterm path t) "\n") where th = bool defaultVariableWeight defaultInitialOpId weightDecls lpo where weightDecls = [] t = parseSingleOrBreak th "bool" "x & (not x)" :: Term path = [] -- :: SubtermPath ------------------------------------------- It cannot choose the Show instance for path = []. But 1) the above `putStr' line contains a subexpression shows (subterm path t) "\n", 2) the imported modules contain the declarations subterm :: SubtermPath -> Term -> Term ... type SubtermPath = [Integer] Hence, it should derive the type for path : [Integer]. Also setting path = [1] or path = [] :: SubtermPath instead of the line path = [] satisfies the compiler. This is not a problem for me to guess to add `:: SubtermPath'. This is a question of curiosity. The compiler sees to which function `path' is fed to, and sees the argument types of this function. Hence, why does not it find the type for `path' ? I am sure that much simpler example is possible (the imported universe is complex), maybe even without overlaps. But maybe, people can explain the effect right for this example as it is? The report is ------------------------------------------ Overlapping instances for Show [a] arising from use of `shows' at GHCBug.hs:5:15-19 Matching instances: Imported from GHC.Show: instance (Show a) => Show [a] Imported from Prelude3: instance Show [Equation] Imported from Prelude3: instance Show [Term] (The choice depends on the instantiation of `a' Use -fallow-incoherent-instances to use the first choice above) In the first argument of `($)', namely `shows path' In the first argument of `putStr', namely `((shows path) $ (shows (subterm path t) "\n"))' In the definition of `main': main = putStr ((shows path) $ (shows (subterm path t) "\n")) where path = [] th = bool defaultVariableWeight defaultInitialOpId weightDecls lpo where weightDecls = [] t = parseSingleOrBreak th "bool" "x & (not x)" :: Term -------------------------------------------------------- Thank you in advance for explanations. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: ANNOUNCE: GHC survey results
by Simon Marlow 29 Jun '05

29 Jun '05

On 28 June 2005 14:11, Bulat Ziganshin wrote: > Tuesday, June 28, 2005, 1:58:13 PM, you wrote: > >> http://www.haskell.org/ghc/survey2005-summary.html >> There's a lot to take in, but it's an interesting read. Enjoy! > > thank you all, processing all the 600 answers was not easy work :) > > i have several comments regarding results of this survey: > > 1) GHCi compiles to bytecode several times faster than GHC makes > unoptimized compilation. can unoptimized GHC compilation just create > bytecode (as Ocaml does)? Do you really mean "several times faster"? My impression is that it's a few percent faster, if at all. Some measurements would be good. We've thought about compiling to persistent byte code in the past, but the gains never seemed to be worth the effort: we'd need a byte-code serialiser and loader. > 2) is your plans to support x86-64 platform includes Windows (and all > other sorts of Unix), or it's for Linux only? Definitely Windows too. I hear the cygwin/mingw tools are still unstable on Windows x64, though. > 3) many users complaining about non-compatibility between GHC > versions. if they mean library interfaces changes then how about using > Pesco's library versioning scheme? (see > http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory) I've read that article, and I think it's an interesting idea. I can't disagree with the arguments put forward, but somehow, the cure seems a bit painful. Cheers, Simon

3 2

RE: ghci - relocation error : libreadline
by Simon Marlow 29 Jun '05

29 Jun '05

On 29 June 2005 14:35, alexandre wrote: > Simon Marlow wrote: > >My guess is that libreadline.so.5 is depending on a later (or > earlier?) >version of libc than the one you have. > > Ok. Then i would need 2 versions of readline and 2 versions of libc > on my system... i'm afraid it's too complex for me to achieve this. > > So i will uninstall readline 5, read the bootstrapping section of the > "building from source" document and try to compile GHC myself. You might find that an earlier version of GHC will work on your system, in which case you can use that to compile up version 6.4. This is much easier than bootstrapping. Cheers, Simon

1 0

RE: ghci - relocation error : libreadline
by Simon Marlow 29 Jun '05

29 Jun '05

On 28 June 2005 16:09, alexandre wrote: > I just installed GHC 6.4 from RPM on a Linux/Mandriva 10.1. > When i try to start GHCI i get the following error message : > ************************************************************************ > GHC Interactive, version 6.4, for Haskell 98. > Loading package base-1.0 ... linking ... done. > /usr/lib/ghc-6.4/ghc-6.4: relocation error: /usr/lib/libreadline.so.5: > symbol __sprintf_chk, version GLIBC_2.3.4 not defined in file > libc.so.6 with link time reference > ************************************************************************ > Could someone help me solve this problem ? For the GHC RPM > installation, i had to install readline 5 first, so i now have two > version of readline on my system : 4.3 and 5 (... and a lot of > application depending on 4.3). Did that error message result from a plain 'ghci' command, or were there any other options? My guess is that libreadline.so.5 is depending on a later (or earlier?) version of libc than the one you have. Cheers, Simon

2 1

RE: ANNOUNCE: GHC survey results
by Simon Peyton-Jones 29 Jun '05

29 Jun '05

| That's fair. I just hope the implicit parameter implementation is | orthogonal enough that it's worth keeping around. It's only *linear* implicit parameters (always regarded as highly experimental) that we might nuke, not implicit parameters themselves. Does anyone out there actually find linear IPs useful? (not all survey results were signed) Simon

1 0

Feedback on Error messages in ghc.
by Peter A Jonsson 29 Jun '05

29 Jun '05

Hello, I read the summary of the survey and noticed you wanted feedback on where error messages could be improved. I looked up some (simple) examples of type errors and ran them through ghc. I do not make any claims to be an HCI expert, just a mere mortal with an opinion. Code: 1 module Test2 where 2 3 fib n = if (3 > n) then 1 else (fib (n - 1) + fib (n - 2)) 4 k = fib 's' Error message: Test2.hs:4: No instance for (Num Char) arising from use of `fib' at Test2.hs:4 In the definition of `k': k = fib 's' This isn't a bad error message in my humble opinion, it does pinpoint that I'm doing something wrong in line 4, and that there isn't an instance for Num Char doesn't come as a surprise. However I think it could have been more helpful by telling me that I tried to pass a Char to a function which expected an (Ord a, Num a) => a as its parameter. Code: 1 module Test4 where 2 3 k :: Int -> Int 4 k l = 2.0*l Error message: Test4.hs:4: No instance for (Fractional Int) arising from the literal `2.0' at Test4.hs:4 In the first argument of `(*)', namely `2.0' In the definition of `k': k l = 2.0 * l One reason this kind of error could happen is an inexperienced user declaring the wrong type for his function, or not knowing that 2.0 would be interpreted as a Fractional. Code: 1 module Test7 where 2 3 len' xs = head (xs) + (length xs) 4 o = len' "GH" Error message: Test7.hs:4: Couldn't match `Int' against `Char' Expected type: [Int] Inferred type: [Char] In the first argument of `len'', namely `"GH"' In the definition of `o': o = len' "GH" I ran this through Hugs version November 2002 and got this error message: ERROR "Test7.hs":4 - Type error in application *** Expression : len' "GH" *** Term : "GH" *** Type : String *** Does not match : [Int] I find the Hugs message more clear, but that might be my background. Code: 1 module Test8 where 2 3 f = head 3 Error message: Test8.hs:3: No instance for (Num [a]) arising from the literal `3' at Test8.hs:3 Possible cause: the monomorphism restriction applied to the following: f :: a (bound at Test8.hs:3) Probable fix: give these definition(s) an explicit type signature In the first argument of `head', namely `3' In the definition of `f': f = head 3 This one I find outright scary. For "wrong = div 3 8 + 1/2" it gives an error message that somewhat helps me guess the error, but the above doesn't even come close to helping me. / Peter

5 5

ANNOUNCE: GHC survey results
by Simon Marlow 29 Jun '05

29 Jun '05

We've finally digested the results of the GHC survey, and you can find our analysis here: http://www.haskell.org/ghc/survey2005-summary.html There's a lot to take in, but it's an interesting read. Enjoy! -- The GHC Team.

7 7