- Glasgow-haskell-users

Re: ANNOUNCE: GHC 5.03.20020204 snapshot release
by Ashley Yakeley 06 Feb '02

06 Feb '02

At 2002-02-05 06:36, Julian Seward (Intl Vendor) wrote: > - newtypes support deriving *any* class for which the > underlying type is also an instance. How about multi-parameter classes where there are instances for the underlying type on more than one parameter: is it possible to specify which parameter the newtype is being derived on? > - Linear implicit parameters: a highly experimental feature. What are they? -- Ashley Yakeley, Seattle WA

1 0

the GCC snapshot
by David Feuer 05 Feb '02

05 Feb '02

What is arbitrarily ranked polymorphism? I don't understand anything past rank 2... Is this arbitrarily ranked polymorphism decidable? This message has been brought to you by the letter alpha and the number pi.

1 0

Linking Problem, ghc 5.02: cannot find -lreadline
by Marc van Dongen 05 Feb '02

05 Feb '02

Dear all, After a long time I decided to start using Haskell again:-) I've downloaded rpm sources (RPMs for SuSE Linux 7.3 (i386, glibc 2.2) from Ralf Hinze: base and docs RPM, and profiling libraries RPM.) from the ghc site and installed them. The only problem I had was that I had to re-install gmp using rpm. So that was great. When I tried to compile some large program I was delighted to see that all object files got created smoothly. At the linking stage I got an error: ''cannot find -lreadline collect2: ld returned 1 exit status'' I couldn't find anything about this on the web or in the mini faq. Anybody there to give me a quick hint how to get around this? Regards, Marc van Dongen -- Marc van Dongen | dongen(a)cs.ucc.ie | Computer Science Department | Western Road | () ASCII ribbon campaign University College Cork | Cork, Ireland | /\ against HTML mail phone: +353 (0)21 4903578 | fax: 4903978 |

2 2

RE: partial evaluation
by Simon Peyton-Jones 04 Feb '02

04 Feb '02

If you say {-# INLINE f #-} on a fn defn for f, it'll get inlined at all its call sites, which is sort of what you want. Just saying 'evaluate this CAF to WHNF' might only inline the outer combinator. Generally, some precise way of controlling what gets evaluated at compile time, a bit less heavyweight than MetaML, would be a fine thing. After all that's what C++ templates are. But the details of a workable design aren't clear to me. Ideas? Simon | -----Original Message----- | From: David Feuer [mailto:David_Feuer@brown.edu] | Sent: 01 February 2002 07:41 | To: glasgow-haskell-users(a)haskell.org | Subject: partial evaluation | Sensitivity: Confidential | | | It seems to me that it might be useful (and probably | fairly easy) to add to GHC a limited sort of partial | evaluation: programmer-designated top-level CAFs could be | evaluated to WHNF during compilation. Termination of that | compiler phase would obviously not be guaranteed, but if | this were possible, I am guessing it would be very useful | for some applications, such as combinator-based parsers. | The parsers would then be generated at compiler time | rather than re-generated every time the parser is | executed. If GHC in fact supports something of this | nature, I would love to hear about it. If it does not, I | would guess it would probably be fairly easy to add to the | end of the code generation phase. | | David Feuer | | This message has been brought to you by the letter alpha and | the number pi. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

2 1

Re: compiling hslibs/xlib
by Jens Petersen 04 Feb '02

04 Feb '02

Jens Petersen <juhp(a)01.246.ne.jp> writes: > "Julian Seward (Intl Vendor)" <v-julsew(a)microsoft.com> writes: > > > Precisely what version of gcc are you using here? > > (gcc -v) > > > > This has been known to happen if you use the default > > gcc on RedHat 6.1 and 6.2. > > Good question. Nothing so old, is the short answer I think. > > The ghc I'm using is from Manuel's ghc-5.02.2-1 rpm (built > on RH72 I believe) is probably with gcc-2.96. > > I am building green-card and xlib with gcc from cvs! > > gcc version 3.1 20020131 (Red Hat Linux Rawhide 3.1-0.20) > > Actually I wanted to build with gcc296, but it (rightly?) > doesn't seem to like "-o" and "-c" in the same command: Ok, scratch that! (I was doing "make CC=gcc296".) Seems it was a gcc-3.1 related problem. :-( When I make green-card and xlib correctly with gcc-2.96 using "ghc -pgmc/usr/bin/gcc296", everything goes through fine. Sorry for the trouble, Jens

1 0

RE: Ticky-ticky profiling (was: GHC 5.02.2 installation/compilationproblems)
by Simon Marlow 25 Jan '02

25 Jan '02

> On Fri, 25 Jan 2002, Nicholas Nethercote wrote: > > > > > Also, when I try to compile for ticky-ticky profiling... > > Further in the ticky-ticky adventure... > > Having compiled the libraries and RTS and other bits for > ticky-ticky, when > I try the -ticky option with ghc I get loads of messages like this at > link-time: > > /homes/njn25/ws/build/ghc/driver/../rts/libHSrts_t.a(GC.t_o): > In function `threadSqueezeStack': > GC.t_o(.text+0x2fe0): undefined reference to > `LDV_recordDead_FILL_SLOP_DYNAMIC' > GC.t_o(.text+0x3010): undefined reference to `LDV_recordCreate' > GC.t_o(.text+0x304d): undefined reference to `LDV_recordCreate' It looks like ticky-ticky has rotted a bit. Some calls to LDV_recordDead_FILL_SLOP_DYNAMIC() and LDV_recordCreate() in Storage.h need to be additionally wrapped in #ifdef TICKY_TICKY. There may be more. If you send me a patch, I'll commit it. Cheers, Simon

1 0

RE: Multiply Recursive Modules
by Simon Peyton-Jones 25 Jan '02

25 Jan '02

We discussed this and yes it seems like a fine idea. Thanks. We should have thought of it ages ago. Not sure how fast we'll implement it, but it's on the list. Simon | -----Original Message----- | From: George Russell [mailto:ger@tzi.de] | Sent: 14 January 2002 16:28 | To: glasgow-haskell-users(a)haskell.org | Subject: Multiply Recursive Modules | | | Writing .hi-boot files is a pain, and "the works" (allegedly) | containing a compiler which | does mutually recursive modules properly seem permanently | gummed up. Therefore may I suggest a new .hs-boot suffix | which compiles Haskell to produce just a .hi-boot file? I | already have two .hs-boot files (except I call them .boot.hs | to make ghc happy) and they seem to work reasonably well. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

RE: GHC 5.02.2 installation/compilation problems
by Simon Marlow 25 Jan '02

25 Jan '02

Hi Nick, > I just installed GHC 5.02.2 (actually, the latest version > from CVS), and > had a strange problem. My first attempt worked ok, but I > screwed something > up, so I junked it and started again from scratch. > > This time, it died part-way through the "make boot" step for ghc > itself, because glafp-utils/mkdependC/mkdependC had not been > built. To fix > the problem I just went to that directory and made mkdependC > myself first, > and then recompiled from $(BUILD), which worked. Does anyone have any > idea why mkdependC may not have been built in the first place? Nothing springs to mind, unless you had explicitly set $(ProjectsToBuild) in your build.mk, and left out glafp-utils. It usually isn't necessary to set $(ProjectsToBuild) as it defaults to building all the projects in the current tree. > Also, when I try to compile for ticky-ticky profiling by setting > GhcCompilerWays=t and GhcLibWays=t in $(BUILD)/mk/build.mk, and then > running "make all" in $(BUILD), it compiles for a short time > and then dies > with this error message: Just set GhcLibWays=t, you don't have to set GhcCompilerWays too (this is for building the compiler itself in a different way). Cheers, Simon

2 2

RE: GHC 5.02.2 installation/compilation problems
by Simon Marlow 25 Jan '02

25 Jan '02

> > > Also, when I try to compile for ticky-ticky profiling... > > > > Just set GhcLibWays=t, you don't have to set > GhcCompilerWays too (this > > is for building the compiler itself in a different way). > > Unless I want to ticky-ticky profile the compiler itself, yes? Yup... if you want to do that, you'll need to do a 2-stage bootstrap and build ticky-ticky libraries (GhcLibWays=t) in the first stage, and build the compiler with ticky-ticky in the second stage. I would just do this by adding -ticky-ticky to GhcHcOpts rather than fiddling with GhcCompilerWays, since I'm less certain the latter works properly. Cheers, Simon

1 0

RE: [Please mail every answer also to wolfgang@jeltsch.net.] No hierarchical module names with GHC 5?
by Simon Marlow 25 Jan '02

25 Jan '02

> I use GHC 5.00.2 on Solaris 2.6 at the university and am unable to use > hierarchical module names --- with and without the > -fglasgow-exts switch. GHCi > notifies me of parse errors on the module name. What is > interesting is that if > my module with hierarchical name imports a module which > cannot be found GHC > tells me that it cannot find the latter module instead of > first recognizing that > the name of the former module is in its opinion illegal and > complaining about > this. Aren't hierarchical module names supported yet in GHC > 5.00.2? At home with > GHC 5.02 under Linux everything works fine. > By the way, I couldn't find anything about hierarchical > module names in the > documentation. 5.00.2 didn't support hierarchical module names, but 5.02 does have the extension. We're not making a lot of noise about it right now because the full switchover is slated for the 5.04 release, when we'll move all the libraries over to use the hierarchical module system. Cheers, Simon

1 0