October 2002 - Glasgow-haskell-users

brain explosion in polymorphic state monad
by mathieu 10 Oct '02

10 Oct '02

Hello, I am trying to define a polymorphic state monad using glasgow extensions and I got a brain explosion of ghc when i try to compile it. Here is the code : newtype StateT s m a = MkStateT (s -> m (a, s)) instance Monad m => Monad (StateT s m) where return x = MkStateT (\s -> return (x, s)) MkStateT m1 >>= k = MkStateT (\s0 -> do (a, s1) <- m1 s0 let MkStateT m2 = k a m2 s1 ) data Thread a = forall b . MkThread (StateT (Thread b) [] a) instance Monad Thread where return = MkThread . return MkThread p >>= k = MkThread ( do x <- p let MkThread p' = k x p' ) I got this error : My brain just exploded. I can't handle pattern bindings for existentially-quantified constructors. In the binding group MkThread p' = k x In the first argument of `MkThread', namely `(do x <- p let MkThread p' = k x p')' In the definition of `>>=': MkThread (do x <- p let MkThread p' = k x p') How can i define (>>=) for my thread monad ? Thanks in advance for any piece of advice, Mathieu -- There are only 10 types of people in the world: Those who understand binary and those who don't.

2 1

non-termination during compilation
by Christian Maeder 10 Oct '02

10 Oct '02

Hi, the following example causes ghc to loop (or run rather long): --- snip --- data U = MkU (U -> Bool) russel :: U -> Bool russel u@(MkU p) = not $ p u x :: Bool x = russel (MkU russel) --- snip --- I think, a compiler should always terminate, shouldn't it!? Compilation succeeds for "russel $ MkU russel" instead of "russel (MkU russel)". (Surely, x is bottom and therefore the example is senseless) Regards Christian

1 0

ObjectIO Library
by Alfonso 10 Oct '02

10 Oct '02

Hello: I have the information that The library ObjectIO is included in the ghc.5.0.4 version, unfortunately I download the msi file for windows (ghc-5-04-1.msi) and the library does not appear in the imports directory after the installation. Have I the wrong information? Do I need to download another msi ? How can I use objectIO with version 5.04.1? thank you Alfonso

2 1

ghc --make and static libraries
by Martin Norbäck 10 Oct '02

10 Oct '02

How do I go about linking to a static library when using --make? If i do ghc --make Module libmodulelib.a then ghc syas: chasing modules from Module,libmodulelib.a and complains about not being able to find the _module_ modulelib.a. Likewise on windows, if I do ghc --make Module modulelib.dll it also complains about not finding the _module_ modulelib.dll. If I specify the object files that makes up modulelib then there are no complaints, likewise, if I link without --make, ghc uses the library just fine. Is this the intended behaviour, and if it is, how do I go about linking with libraries when using --make? Regards, Martin

1 1

RE: ObjectIO Library
by Simon Peyton-Jones 10 Oct '02

10 Oct '02

I have the information that The library ObjectIO is included in the ghc.5.0.4 version, unfortunately I download the msi file for windows (ghc-5-04-1.msi) and the library does not appear in the imports directory after the installation. Have I the wrong information? Do I need to download another msi ? How can I use objectIO with version 5.04.1? The message below is the most recent I know about for ObjectIO. It's not yet included as a standard part of the GHC distribution, though I hope it will become so in due course. Simon -----Original Message----- From: Krasimir Angelov [mailto:ka2_mail@yahoo.com] Sent: 04 September 2002 19:01 To: haskell Cc: amelende(a)yahoo.es Subject: ANN: ObjectIO update for GHC-5.04 Hi, Haskellers An update is available for ObjectIO for GHC-5.04. Just extract the package over the GHC directory to update the library. More information: http://haskell.cs.yale.edu/ObjectIO This is the package: http://haskell.cs.yale.edu/ObjectIO/ObjectIO_update.zip Krasimir

1 0

Re: Building Both "Regular" and "Profiling" Libraries
by Ashley Yakeley 10 Oct '02

10 Oct '02

At 2002-10-10 01:23, Ketil Z. Malde wrote: >Ashley Yakeley <ashley(a)semantic.org> writes: > >> I did notice that for -osuf you seem to need the '.' but for -hisuf you >> don't... > >Weird, I've never seen that behavior (GHC 5.02 and 5.04, x86-Linux and >Sparc-Solaris). I just checked with 5.04 on my Linux box, and 5.02 on >a Sun, just to make sure. > >What system and compiler version are you using? My mistake, I'm using -o, which overrides -osuf... -- Ashley Yakeley, Seattle WA

1 0

RE: Building Both "Regular" and "Profiling" Libraries
by Ashley Yakeley 10 Oct '02

10 Oct '02

At 2002-10-09 07:48, Hal Daume III wrote: >Is this the sort of thing you're looking for? Yes, thanks. I now have these in my Makefile: HCPOPTS = -prof -hisuf p_hi -osuf .p_o -auto-all +RTS -K32M -RTS depend-entries: $(HC_SRCS) $(HC) -M -optdep-s -optdepp $(HCFLAGS) $^ I did notice that for -osuf you seem to need the '.' but for -hisuf you don't... -- Ashley Yakeley, Seattle WA

2 1

RE: Building Both "Regular" and "Profiling" Libraries
by Simon Peyton-Jones 09 Oct '02

09 Oct '02

A much more helpful reply than mine; I'll add it to the user manual. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 09 October 2002 15:48 | To: Ashley Yakeley | Cc: Simon Peyton-Jones; GHC List | Subject: RE: Building Both "Regular" and "Profiling" Libraries | | What I do is I have a few aliases: | | ghcm: ghc --make ... -osuf sun4.o -hisuf sun4.hi | ghcp: ghc --make ... -osuf sun4.prof.o -hisuf sun4.prof.hi -prof | -auto-all | | These are set in my .cshrc file so the "sun4" is actually the $ARCH | variable of the machine I'm currently on (this enables me to have i686 and | sun4 binaries coexisting in a friendly manner). | | Then, when I want a normal build, I do: | | ghcm Foo.hs -o Foo | | and for a profiled: | | ghcp Foo.hs -o Foo_prof | | It saves a lot of build time. | | Is this the sort of thing you're looking for? | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | On Wed, 9 Oct 2002, Ashley Yakeley wrote: | | > At 2002-10-09 04:21, Simon Peyton-Jones wrote: | > | > >Yes there is. In your build.mk, set GhcLibWays = p | > > | > >This is discussed a lot in the Building Guide, which I commend to you if | > >you are building GHC. | > | > I'm not building GHC. I just want to build my own stuff and I don't have | > a build.mk... | > | > -- | > Ashley Yakeley, Seattle WA | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | >

1 0

RE: Building Both "Regular" and "Profiling" Libraries
by Ashley Yakeley 09 Oct '02

09 Oct '02

At 2002-10-09 04:21, Simon Peyton-Jones wrote: >Yes there is. In your build.mk, set GhcLibWays = p > >This is discussed a lot in the Building Guide, which I commend to you if >you are building GHC. I'm not building GHC. I just want to build my own stuff and I don't have a build.mk... -- Ashley Yakeley, Seattle WA

2 1

RE: unsafePerformIO
by Simon Marlow 09 Oct '02

09 Oct '02

> But it is a fact that many of us have at least some idea of > what happens "under the hood" when we use unsafePerformIO. > This is also described in your paper "Stretching the storage > manager: weak pointers and stable names in Haskell". > > However, I for example have no idea what happens when > unsafely executing something that throws exceptions, > performs a forkIO, something that uses MVar's, etc. Exceptions: an exception raised by the computation inside unsafePerformIO will be propagated to the enclosing expression, as per the normal semantics for imprecise exceptions. The exception raised by an application of unsafePerformIO may of course also be imprecise; consider 'unsafePerformIO $ (1/0 + error "foo") `seq` return ()'. The behaviour of forkIO and other side-effecting operations inside unsafePerforIO can I think be explained by the following statement: if an expression "unsafePerformIO e" has been reduced to head normal form, then all the I/O computations in e have been performed. The exact timing of the evaluation is underspecified, just as any other expression in Haskell. However, if you're using unsafePerformIO with real side effects, then I suspect that what you're doing is highly dodgy and you should find another way to do it :-) Does that help? As for sharing, we currently don't provide any guarnatees, although we should. It is currently the case that if you write a = unsafePerformIO (putStr "hello") b = unsafePerformIO (putStr "hello") and both a and b are evaluated, then you may get either one or two "hello"s on stdout. You can currently make things more deterministic by (a) adding NOINLINE pragmas for a and b, and (b) using the flag -fno-cse to disable common sub-expression elimination. Then you'll get exactly two instances of "hello" on stdout, although we won't guarantee that behaviour for ever. At some point we'll fix it so that unsafePerformIO applications are never duplicated or coalesced. If you're interested in when unsafePerformIO is "safe" to use, see: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-July/003683. html (and see my followups for an alternative view). Cheers, Simon

2 1