- Glasgow-haskell-users

[nhc-bugs] confhc does not recognize ghc 5.*
by Malcolm Wallace 23 Oct '01

23 Oct '01

Mieszko Lis <elf(a)sandburst.com> writes: > i ran into a compiler-detection bug in building nhc98 (the 1.10 tarball, > but the same bug seems to be in cvs and earlier versions): the build > process fails to detect the default ghc 5.02 installation on my debian > linux machine as well as the ghc 5.00.2 installation on a redhat 7.1 box > nearby. > > the problem turns out to be that script/confhc looks through the ghc > executable for the wrong stuff (at least in the installations i > mentioned above). i attached a patch (against the cvs tree) to fix > this at least on these debian and redhat installations. Here is the essential part of the patch: - GHCDIR=`grep '^libdir' ${whichGHC} | head -1 | sed 's/^libdir=.$.*$./\1/'` + GHCDIR=`grep '^TOPDIROPT' ${whichGHC} | head -1 | sed 's/^TOPDIROPT="*-B$[^";]*$.*/\1/'` However, this does not work on my (Slackware Linux) machine. In the driver script for ghc-5.02, I see the following two lines: libdir='/usr/malcolm/local/lib/ghc-5.02' TOPDIROPT="-B$libdir"; which means that the original confhc gives the correct path (/usr/malcolm/local/lib/ghc-5.02), but the patched confhc gives an incorrect path symbol ($libdir). Can someone at ghc central confirm whether this part of the ghc-5.02 driver script differs, depending on package and platform? And if so, what is the best way to detect which variation applies? Regards, Malcolm

2 1

RE: Blocking IO in module Socket
by Simon Marlow 22 Oct '01

22 Oct '01

> Why doesn't Socket.accept call threadWaitRead before entering the > C-call (which will block the entire RTS when used in conjunction > with Concurrent)? Is there any design decision involved? The call doesn't block, because the socket is set to non-blocking mode. Or have you perhaps observed different behaviour? It works here. Cheers, Simon

2 1

Blocking IO in module Socket
by Volker Stolz 22 Oct '01

22 Oct '01

Why doesn't Socket.accept call threadWaitRead before entering the C-call (which will block the entire RTS when used in conjunction with Concurrent)? Is there any design decision involved? -- Volker Stolz * vs(a)foldr.org * PGP + S/MIME

1 0

5.02 MonadError Broke My Code
by Ashley Yakeley 22 Oct '01

22 Oct '01

MonadError seems to have been redefined in 5.02 to have a fundep: 5.00.2: class (Monad m) => MonadError e m 5.02: class (Monad m) => MonadError e m | m -> e Why? Perhaps the IO Monad can have only one kind or level of error, but why can't other Monads have more? Anyway, because of GHC's naive instance overlapping checking, it broke my code: instance (JVMMonad m) => MonadError ThrowableRef m where { throwError = jvmThrow; catchError = jvmCatch; }; because GHC thinks it might overlap with the Prelude's instance MonadError Exception IO -- Ashley Yakeley, Seattle WA

1 0

Strict functions
by Ian Lynagh 21 Oct '01

21 Oct '01

Hi all I've been reading the GHC docs and they say that strict functions are good for space and time. Section 6.2 goes on to explain how to read the .hi files to determine the strictness of a function. However, it doesn't explain all the cases I am seeing. Example of the ones I've noticed are: V S(L)V AAAb m C(V)L What do these mean? And more importantly, how good are they? Also, the prelude definition of zipWith has LVL whereas the following definition has LVV. Why is something like the following not used? > zipWith :: (a->b->c) -> [a] -> [b] -> [c] > zipWith f (a:as) (b:bs) = f a b : zipWith f as bs > zipWith _ _ [] = [] > zipWith _ _ _ = [] Thanks Ian

3 3

Re: Multi-parameter OOP
by Ashley Yakeley 19 Oct '01

19 Oct '01

At 2001-10-19 08:02, George Russell wrote: >a naive user (like me a month ago) might expect that this to work, so that >toBool (WrappedA a) (WrappedB b) will return False unless a is an A1, and >b a B1, in which case it returns True. I think existential types are arranged so that Haskell never needs to store type information in them at run-time. So you'll never be able to do dynamic OOP with them. One possible extension to Haskell for dynamic OOP, which I never tire of suggesting, is the extensible datatype, for instance: module P data BaseType = B1 | B2 | _ module Q data DerivedType = D1 | D2 data BaseType |= BD DerivedType -- Ashley Yakeley, Seattle WA

1 0

Re: Multi-parameter OOP
by Marcin 'Qrczak' Kowalczyk 19 Oct '01

19 Oct '01

Fri, 19 Oct 2001 17:02:54 +0200, George Russell <ger(a)tzi.de> pisze: > So is there any other way of doing this sort of dynamic lookup at > runtime, in a reasonably neat way? There is module Dynamic. I don't know if it helps or is reasonably neat. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Your Property Portfolio
by Smith Hawkshaw Properties 19 Oct '01

19 Oct '01

1 0

Why is (monad) elegance so costly?
by marku＠cs.waikato.ac.nz 19 Oct '01

19 Oct '01

I am about to rewrite my Z animation tool (JAZA) in a style that makes more intensive use of state monads. However, my experiments with a simplified lambda-calculus example shows that (with GHC 5.00) the state monad is dramatically less efficient than the simple identity monad: 4 TIMES SLOWER, and 7 TIMES MORE MEMORY! Is this normal? Acceptable? Am I doing something wrong? Can anyone suggest ways of reducing these overheads? (I am very keen to use state-monads if possible, because it allows my 'eval' code to be generic over the monad that is used, which allows me to reuse the code with other similar monads. In fact, I am using it to simulate the 'visitor' design pattern from OO langs.) Hugs gives slightly smaller differences (3 times more reductions and 3.5 times more cells), but I had hoped that GHC would be able to optimize most of the state monad overhead away (especially when the monad uses newtype)? My code and speed measurements are attached. Mark.

1 0

RE: Working character by character in Haskell
by Jan-Willem Maessen 19 Oct '01

19 Oct '01

"Simon Marlow" <simonmar(a)microsoft.com> writes: > To really match the C program, you need to use IOExts.hGetBuf and > IOExts.hPutBuf, and do the operations on raw characters in memory. > Using a UArray of Word8 would be better, but there aren't any > operations to do IO to/from a UArray yet (actually I've written > these, but they aren't in the tree yet). So why don't getContents / putStr / etc. deforest cleanly to calls to hGetBuf and hPutBuf? I'm genuinely curious; my own experience in this direction is "The engineering is challenging". These functions are so commonly used, though---and they're vastly easier to use, actually portable, etc. The effort would surely be repaid. Plus, I'm curious to hear about any challenges which may be involved in pulling this off. :-) If it's genuinely tricky, the tricks are likely to be generally useful for other stream-ish things. -Jan-Willem Maessen Eager Haskell Project jmaessen(a)mit.edu

1 0