- Glasgow-haskell-users

Solaris x86 package
by Georg Sauthoff 14 Jun '06

14 Jun '06

Hi, finally I built a working ghc 6.4.2 [1] for Solaris x86. Since I couldn't find any binary package at the GHC homepage, this was a little time consuming procedurce (starting with unregistered build etc). Thus I want to save other Solaris x86 users from that by contributing a Solaris x86 binary package for the ghc web page. How should I proceed? Should I open a ticket at the homepage for that? What should I consider? Is 'make binary-dist' the right target? And what about some ghc libraries? Is it ok to exclude some, like opengl, readline and X11 related packages, because with them the binary package would be too specific to my Solaris environment (or dependent at a specific readline version)? I guess, because 6.4.3 includes some fixes, it make sense to do the packaging for that version instead of 6.4.2. If no one packages for Solaris sparc, I could do that, too. Regards Georg Sauthoff [1] with non-threaded rts

2 5

ghc sparc NCG
by Georg Sauthoff 13 Jun '06

13 Jun '06

Hi, at http://hackage.haskell.org/trac/ghc/wiki/Platforms I read, that the Sparc NCG 'is bitrotted' - does that mean, that it is unmaintained, but used by default at sparc? I am asking because the solaris sparc system has a ghc 6.2 installed, which generates .s files. Or does NCG means something else? Regards Georg Sauthoff

4 6

Monomorphism restriction - is this still needed for efficiency?
by Brian Hulley 12 Jun '06

12 Jun '06

Hi - I'm wondering if the monomorphism restriction is now just an anachronism from Haskell 98 or if it is still needed for efficiency ie should I just now use -fno-monomorphism-restriction when compiling all my code to consign it to the dustbin of history? :-) A related question is, if it can still improve efficiency when applied to local bindings, whether it would be worthwhile to have an additional option to switch monomorphism off for top level bindings but still keep it for local bindings, since I can't think of any situation where I don't want a top level binding to be fully polymorphic. Does anyone know of any situation where a top level binding should not be fully polymorphic? Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

2 2

Re: [nightly] 07-Jun-2006 build of HEAD on i386-unknown-mingw32 (bling)
by Bulat Ziganshin 07 Jun '06

07 Jun '06

Hello sof, Wednesday, June 7, 2006, 6:27:10 PM, you wrote: > Subject: [nightly] 07-Jun-2006 build of HEAD on i386-unknown-mingw32 (bling) > mingw .tar.gz ready to be uploaded to: > http://www.haskell.org/ghc/dist/current/dist/ i don't see this upload, last mingw version is 28 march -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

how to get more detail for: <<loop>>
by Johannes Waldmann FbIMN 07 Jun '06

07 Jun '06

How can I get more information if my ghc-compiled program halts with "<<loop>>" What kinds of cyclic dependencies does the runtime system actually recognize? Thanks -- Johannes Waldmann

2 1

example for recursive import
by Serge D. Mechveliani 07 Jun '06

07 Jun '06

Johannes Waldmann <waldmann(a)imn.htwk-leipzig.de> writes on Junne 6 2006 > As for recursive module imports, > could you perhaps show an example where this occurs. > I found that in my code, I can re-arrange things > so as to remove the cyclic dependency. Best regards, Consider the following situation, which often happens. * A function f calls for g and for h, each g and h calls for f. * f is a large implementation, gathered in the module F. * g and h are the two important special cases for f, each implemented as a large source, according to its very particular principles. * Each of these three functions needs only a small part of the name space needed for other two functions (modules are also for structuring the name space). >From the conceptual point of view, we need at least three modules in this case. This way this program is easier to write and to understand. But the module import occurs cyclic. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 4

why hs-boot
by Serge D. Mechveliani 07 Jun '06

07 Jun '06

For recurive import, GHC suggests using an hs-boot file to "get started". So far, I do not know, what does this mean. But I do not understand, why at all GHC needs any help in this situation. Look: * we write the two modules importing each other, * reading these modules, we understand the computational meaning of the whole program. Hence, it must be compiled according to this meaning. Why does GHC need additional help? Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

recursive import
by Serge D. Mechveliani 06 Jun '06

06 Jun '06

People, Who knows, please, how usable are currently recursive module imports in Haskell, in GHC ? Is it essentially more difficult to `make' and support a project which has 50 modules, and half of all the module pairs import each other? Is recursive import in Haskell-98 ? Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

5 5

ghci, sourcing
by Frederik Eaton 06 Jun '06

06 Jun '06

Hi, Is there a way to source a file in ghci? I have a series of initialization commands which I would like to run every time I do a certain set of experiments, and I've put them in a file. Is it best just to copy and paste the file into ghci? Frederik -- http://ofb.net/~frederik/

2 2

recursive import
by Serge D. Mechveliani 06 Jun '06

06 Jun '06

Concering the current state of recursive import, Simon Peyton-Jones <simonpj(a)microsoft.com> writes on 5 Jun 2006 > [..] > > GHC's module-at-a-time compilation model means that GHC needs an hs-boot > file to "get started". The manual tries to explain what you can and > can't do. If you follow the rules it works pretty well. We use > recursive modules extensively for compiling GHC itself, and it's just > fine with 'make'. (ghc -M does the right thing.) > > [..] Thank you for the explanation. And how does this feature interact with packages, with making via Cabal ? Will Cabal work with recursive imports and with ghc-options: -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports -O -prof -auto-all ? Generally, I tend to use recursive modules because they simplify the global algorithm presentation. But fear of technical difficulties in the project support. Maybe, I would try this recursion. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2