January 2002 - Glasgow-haskell-users

notes on ghc-5.02.2. Reply
by S.D.Mechveliani 24 Jan '02

24 Jan '02

To my notes on ghc-5.02.2 Simon Marlow writes >> * up-arrow key does not work in ghci, >> and it worked in binary installation. >> Probably, some library was not found. How to fix this? > Do you have the readline-devel RPM installed? This is needed to compile > GHC with readline support. I run ghc here on two machines. And it appears now that both are under Debian Linux. Some people here say that this RPM does not go under Debian. Maybe, GHC can take care of Debian? Would it help now, after `make all', `make install', setting LD_LIBRARY_PATH or such, making symbolic links? >> * The interpreted code looks 2-3 times larger than compiled one. >> DoCon-library has size 11 Mb, >> .o files of compiled test take less than 2 Mb, >> test loading ghci -package docon T_ +RTS -Mxx -RTS >> >> needs xx = 12 for the compiled full test T_, >> 31 for interpreted T_. >> If DoCon-library is out of the heap reserved by -M (is it?), >> then, we have that interpreted code is 2.6 times larger. >> Is this due to large interaces kept in heap? > Compiled code isn't loaded into the heap, so it isn't included in the > size you give to -M. > > What are "interaces"? A typo. Module interfaces. In any case, I could confuse things, not understanding these implementation details, only observe that the interpreted code looks 2-3 times larger. Maybe, it is natural, maybe not, I do not know. Another question: am I in glasgow-haskell-users.. ? I am responding to Simon's respond to my letter to glasgow-haskell-users.. sent a couple of hours ago, and I had not recieved this my letter, so far. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

RE: notes on ghc-5.02.2
by Simon Marlow 24 Jan '02

24 Jan '02

> Some questions > -------------- > > * up-arrow key does not work in ghci, > and it worked in binary installation. > Probably, some library was not found. How to fix this? Do you have the readline-devel RPM installed? This is needed to compile GHC with readline support. > I have stored config.log of `./configure ...' > and makeall.log of `make all'. > `make boot' (before `make all') did nothing and issued a > message recommending to run a thing something in some > subdirectory, and I skipped this command at all. Do I mistake? > > * the directory /share always neighboured to /bin /lib > in the installation directory. Why it is absent now? > Maybe, the up-arrow bug is related to this? /share is created when there is documentation to install. Probably you didn't install the documentation (it isn't installed by default). > * Where to find the ghc manual in the .ps form, > like set.ps provided by binary installation? There's a pre-formatted version on the GHC web site: http://www.haskell.org/ghc/docs/latest/set.ps > * The interpreted code looks 2-3 times larger than compiled one. > DoCon-library has size 11 Mb, > .o files of compiled test take less than 2 Mb, > test loading ghci -package docon T_ +RTS -Mxx -RTS > > needs xx = 12 for the compiled full test T_, > 31 for interpreted T_. > If DoCon-library is out of the heap reserved by -M (is it?), > then, we have that interpreted code is 2.6 times larger. Compiled code isn't loaded into the heap, so it isn't included in the size you give to -M. > Is this due to large interaces kept in heap? What are "interaces"? Cheers, Simon

1 0

notes on ghc-5.02.2
by S.D.Mechveliani 24 Jan '02

24 Jan '02

Dear GHC, Here are some comments on ghc-5.02.2. I have tested it in the following way. 1. Installed binary = ghc-5.02.2-i386-linux-unknown. 2. Compiled ghc-5.02.2-source with binary for linux-i386, under empty mk/build.mk, removed binary installation. 3. Compiled a large Haskell project DoCon under -O (making package, -fglasgow-exts, overlappings ...) 4. Run DoCon test. It looks all right. * It spends the memory in a better way when making a project and loading interpreted modules. * It looks fixed the bug with the value visibility in ghci in (let f = ...; let g = h f ...) Some questions -------------- * up-arrow key does not work in ghci, and it worked in binary installation. Probably, some library was not found. How to fix this? I have stored config.log of `./configure ...' and makeall.log of `make all'. `make boot' (before `make all') did nothing and issued a message recommending to run a thing something in some subdirectory, and I skipped this command at all. Do I mistake? * the directory /share always neighboured to /bin /lib in the installation directory. Why it is absent now? Maybe, the up-arrow bug is related to this? * Where to find the ghc manual in the .ps form, like set.ps provided by binary installation? * The interpreted code looks 2-3 times larger than compiled one. DoCon-library has size 11 Mb, .o files of compiled test take less than 2 Mb, test loading ghci -package docon T_ +RTS -Mxx -RTS needs xx = 12 for the compiled full test T_, 31 for interpreted T_. If DoCon-library is out of the heap reserved by -M (is it?), then, we have that interpreted code is 2.6 times larger. Is this due to large interaces kept in heap? Please, advise, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Why a context reduction stack overflow?
by Mike Gunter 23 Jan '02

23 Jan '02

Compilation, with ghc 5.02, of the following program: data Zero = Zero deriving Show data Succ a = Succ a deriving Show -- Compilations succeeds with the following line uncommented. -- t :: Succ Zero -- <============================= t = Zero `p` (Succ Zero) class P a b c | a b -> c where p :: a -> b -> c instance P Zero a a where p Zero a = a instance P a b c => P b a c where p b a = p a b main = putStrLn $ "Hello." succeeds with the indicated line uncommented. With it commented-out, the compilation fails with: Flip.hs:6: Context reduction stack overflow; size = 21 Use -fcontext-stack20 to increase stack size to (e.g.) 20 `P (Succ Zero) Zero c' arising from use of `p' at Flip.hs:6 `P Zero (Succ Zero) c' arising from use of `p' at Flip.hs:6 `P (Succ Zero) Zero c' arising from use of `p' at Flip.hs:6 `P Zero (Succ Zero) c' arising from use of `p' at Flip.hs:6 ... `P (Succ Zero) Zero c' arising from use of `p' at Flip.hs:6 `P Zero (Succ Zero) c' arising from use of `p' at Flip.hs:6 `p at [Zero Succ Zero c]' arising from use of `p' at Flip.hs:6 When generalising the type(s) for t . Why? thanks, mike gunter

1 0

RE: GHC Poll: scope in GHCi
by Simon Marlow 23 Jan '02

23 Jan '02

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > :m [+|-] [*]M1 ... [*]Mn (n >= 0) > > (nit: I would paraphrase to make n >= 1, since you start numbering at > 1. Wrap the whole M-list with optionality brackets if that's the > intended meaning (setting the scope to nothing? The default?)) The n >= 0 trick is used in the Haskell report so I thought it might be familiar to people here :-) > > Currently the non-* form isn't supported for compiled modules, and > > attempting to set an unsupported scope results in an error. > > Since, if I understand correctly, there is no explicit way of > differentiating between compiled and interpreted modules, so why not > simply fall back to interpreting the module in question? Because that requires a reload, which might be counter-intuitive (:m doesn't otherwise cause loading of modules), and furthermore it would erase any bindings made so far on the command line. But :m might emit a message like the following if you attempt to set the scope to the top-level of a compiled module: > :m Foo module 'Foo' is compiled; to include its top-level scope, try ':interpret Foo', ':reload', then ':m Foo'. Where ':interpret Foo' would force interpreting of module Foo starting from the next reload. Cheers, Simon

1 0

RE: GHC Poll: scope in GHCi
by Simon Marlow 23 Jan '02

23 Jan '02

Folks, Dean Herington suggested another possible syntax for the :module command. To paraphrase, the new syntax would be: :m [+|-] [*]M1 ... [*]Mn (n >= 0) Using the convention that [] indicates an optional syntactic element, '|' indicates choice, and M1 ... Mn are module names. - with no +/-, the command sets the scope - with +, the indicated modules are added to the scope - with -, the indicated modules are removed from the scope - 'M' means include the full top-level scope of module M - '*M' means include just the exports of module M Currently the non-* form isn't supported for compiled modules, and attempting to set an unsupported scope results in an error. I think this is simpler than the original suggestion, although it makes some cases erroneous where the previous form would "do the right thing". Eg. Now you have to say ':m + *IO' to import IO, whereas previously you could just say ':m +IO'. I think I'd probably ":def :import (return . (":m + *" ++))". On the other hand, the new form separates what is really just an implementation restriction (that we can't load the top-level scope of a compiled module) from the user interface, which is a good thing. At some point we might lift the restriction, which we could do without changing the meaning of the :m command. Unless anyone has any more suggestions or objections, I'm inclined to go with this syntax. Cheers, Simon > -----Original Message----- > From: Dean Herington [mailto:heringto@cs.unc.edu] > Sent: 09 January 2002 15:59 > To: Simon Marlow > Cc: GHC Users Mailing List > Subject: Re: GHC Poll: scope in GHCi > > > A minor suggestion: Let ":m *M" apply to compiled modules as well as > interpreted. In other words, ":m +M" requests all top-level entities > (accepting only exported ones for compiled modules) while ":m > *M" requests > only exported entities (whether the module is compiled or > interpreted). > > More generally, though, I dislike allying the "all / exported > only" choice > with the "add a module to the scope" command; they should be specified > independently. In particular, one should be able to make the > choice for > each of the modules in the ":m M1..Mn" command. (Otherwise, > how can one > reasonably request a scope consisting of only the exported > entities from a > single interpreted module?) > > A question: What is the syntax of the "M1..Mn" form? > > I like Koen Claessen's suggestion that one be able to request > all top-level > names from a compiled module. > > Here's a variant of Simon's proposal that addresses the above > concerns: > > * Let a <mods> be either the name of a module (implying the > set of all > top-level names in that module) or a square-bracketed, > space-separated list > of module names (implying the set of names exported from the modules). > > * Let a <modslist> be a list of <mods>s. Whitespace must separate > adjacent <mods>s when neither is in square brackets. > > * Let the ":module" command take an optional '+' or '-' > followed by a > <modslist>. '+' indicates additions to the scope; '-' indicates > subtractions from the scope; absence of both indicates > redefinition of the > scope. > > Square bracketing is suggested for indicating that only > exported names are > desired, to match the prompt syntax. An alternative for both > would be to > prefix each such module name by, say, '*'. Examples of these two > alternatives: > > Main[IO]> :module + [Char Monad] Foo > Main Foo[IO Char Monad]> > > or > > Main *IO> :module + *Char *Monad Foo > Main *IO *Char *Monad Foo> > > I think I prefer the latter. > > Dean > >

2 1

Compiling the Hugs Graphics Library (HGL) with GHC?
by Christoph Lueth 22 Jan '02

22 Jan '02

Morning Gentlemen, may I ask if anybody had any success using the Hugs Graphics Library with ghc? I did get it to compile and link, but it insists displaying most graphics in black on a black background which somewhat diminishes the viewing enjoyment. I'm using GreenCard 2.03 and ghc-5.02.2, compiling via the FFI (-target=ffi), since getting gc to generate ghc code (-target=ghc) doesn't work; or rather, it produces code which ghc doesn't like. And, yes I know about HOpenGL and other graphics libraries for ghc -- quick word why I want to do exactly this: we're using hugs for teaching, and the Hugs Graphics Library makes a nice addition to an introductory course in Haskell. I wanted to demonstrate that Haskell is fast enough to write wee games in (Asteroids, to be precise), if one is using a compiler. Thanks, --C.

3 2

RE: GHC Poll: scope in GHCi
by Simon Marlow 22 Jan '02

22 Jan '02

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > Ok, so in general a 'scope' can be constructed by combining: > > > > 1. the full top-level scope from zero or more > *interpreted* modules > > 2. the exports of zero or more modules (interpreted or compiled) > > 3. any temporary bindings made on the command line > > I'd like to suggest one more thing that it would be nice to have in > scope. I would like every loaded module to be imported "qualified" > into the scope. (In fact, I would prefer if this were the default, > although I suppose it might be useful to have a way to turn it off.) Sure. In fact, GHCi already supports this: Prelude> Time.getClockTime >>= IO.putStrLn . show Tue Jan 22 16:33:58 GMT 2002 Cheers, Simon

1 0

RE: GHC Poll: scope in GHCi
by Simon Marlow 22 Jan '02

22 Jan '02

> | I'm currently showing the scope in the prompt, with > | the modules from which we're taking the exports only > | surrounded by square brackets. > > It is nice to show the difference. What I am looking for > however is to get everything defined in a compiled module > into scope. > > One solution might be to just interpret the module, even > when there is a compiled version of it. > > The current way to do it is to remove the .o file, and > reload. This is very unsatisfactory I think. You can also touch the .hs file of course, which is slightly less drastic. But yes, I think we could provide a way to say "ignore the compiled version of module M". Cheers, Simon

1 0

RE: 5.02.2 binary incompatible with 5.02.1
by Martin Norbäck 22 Jan '02

22 Jan '02

tis 2002-01-22 klockan 15.48 skrev Simon Marlow: > > I just noted that 5.02.2 is binary incompatible with 5.02.1 which is a > > minor nuisance, since I must then recompile all my .o-files. > > > > This was not mentioned in the release notes, perhaps it was > > unintentional? > > Yes, this is the case for *all* releases of GHC, even minor ones(*). It would be nice to improve this situation, but unfortunately retaining binary compatibility is not straightforward due to the high level of coupling between compiled modules - the price you pay for aggressive inter-module optimistaion. Ok, then I would like to make a request that this fact is caught before linking, since the linker error is a bit non-informative. There is a version string in the .hi-file, but it only says 502, which is the same in both releases, so it doesn't help. Perhaps ghc should put 5022 there? Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped

1 0