- Glasgow-haskell-users

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

RE: 5.02.2 binary incompatible with 5.02.1
by Simon Marlow 22 Jan '02

22 Jan '02

> | 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. > > Unfortunately yes, due to the fix to big-block allocation. Ah yes, that too. Simon

1 0

RE: 5.02.2 binary incompatible with 5.02.1
by Simon Marlow 22 Jan '02

22 Jan '02

> 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. Cheers, Simon (*) Actually this may not be strictly true, but binary compatibility would be accidental rather than intended.

1 0

RE: 5.02.2 binary incompatible with 5.02.1
by Julian Seward (Intl Vendor) 22 Jan '02

22 Jan '02

| 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. Unfortunately yes, due to the fix to big-block allocation. | This was not mentioned in the release notes, perhaps it was | unintentional? I think we forgot to mention this. I guess we should, since you wouldn't expect it from only a patchlevel change. J

1 0

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

22 Jan '02

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? On the other hand, the time of compilation of my happy parser decreased from 20 minutes to <10 minutes, probably because of the lower memory usage. So, I am not that angry :) 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

RE: Packages
by Simon Marlow 22 Jan '02

22 Jan '02

> QForeign under ghc consists of several packages with some > interdependencies. > I'm getting warnings during compilation, e.g.: > > /usr/local/bin/ghc -c -O -Wall -fglasgow-exts -package lang > -package data -package concurrent -package posix -iexamples > -ilib -Iexamples -Ilib -package-name qforeign-curses > examples/Curses.hs > > Curses.hsc:1: > Warning: Module `QIntegral' is located in package > `qforeign-curses' > but its interface file claims it is part of > package `qforeign' > > I understand what it means but I don't know how to fix it. QIntegral > should be in package qforeign, but's found by -ilib during compilation > of other modules which use it because it's not installed yet! The only real solution is to install the qforeign package before using its modules in another import. But 'installing' the package just consists of generating a suitable package.conf file and using the -package-conf flag. The -i flag should only really be used to bring into scope modules in the same package as the one being compiled. The warning is relatively harmless, it might just result in your .hi files containing some extra dependencies that they might not otherwise have (inter-package dependencies aren't normally recorded in .hi files because packages are assumed to be "stable"). Perhaps the package story could be simplified - I need to work through the ramifications first though. Cheers, Simon

1 0