September 2008 - Glasgow-haskell-users

GADTs and functional dependencies
by Wolfgang Jeltsch 29 Sep '08

29 Sep '08

Hello, please consider the following code: > {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} > > data GADT a where > > GADT :: GADT () > > class Class a b | a -> b > > instance Class () () > > fun :: (Class a b) => GADT a -> b > fun GADT = () I’d expect this to work but unfortunately, using GHC 6.8.2, it fails with the following message: > FDGADT.hs:12:11: > Couldn't match expected type `b' against inferred type `()' > `b' is a rigid type variable bound by > the type signature for `fun' at FDGADT.hs:11:16 > In the expression: () > In the definition of `fun': fun GADT = () What’s the reason for this? Is there a workaround? Does this work in 6.8.3 or 6.10.1? Thank you in advance. Best wishes, Wolfgang

7 15

6.10-candidate tested
by Serge D. Mechveliani 29 Sep '08

29 Sep '08

Dear GHC developers, I have tested ghc-6.10.0.20080921 on * making it by ghc-6.8.2, * making it by itself, * the DoCon and Dumatel applications. It looks all right. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

6 10

newSession gone from GHC API
by Mitchell, Neil 29 Sep '08

29 Sep '08

Hi I just noticed that newSession has been removed from the GHC API. Unfortunately, this breaks nearly all examples on the web: http://www.haskell.org/haskellwiki/GHC/As_a_library http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API Could someone fix those up, to show the new style of interaction? Also are the breaking changes to newSession in GHC 6.10, or only in GHC Head? Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

2 1

Re: ANNOUNCE: GHC 6.10.1 beta
by humasect 28 Sep '08

28 Sep '08

uh oh.. ~/Haskell/bin/ghc +RTS -N2 -RTS -hidir ../build/ -odir ../build/ -threaded -package ghc -main-is Shell --make Shell -DCALLCONV=ccall [4 of 4] Compiling Shell ( Shell.hs, ../build/Shell.o ) Linking Shell ... ld: atom sorting error for _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.10.0.20080927.a(LibFFI.o) ld: atom sorting error for _ghczm6zi10zi0zi20080927_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi10zi0zi20080927_LibFFI_Czuffizucif_closure_tbl in /Users/humasect/Haskell/lib/ghc-6.10.0.20080927/ghc-6.10.0.20080927/libHSghc-6.10.0.20080927.a(LibFFI.o) When linking with new GHC api after converting this shell to use it ( http://hackage.haskell.org/trac/ghc/wiki/GhcApiStatus) -lyndon

3 3

Re: ANNOUNCE: GHC 6.10.1 beta
by humasect 25 Sep '08

25 Sep '08

installPackage: internal error: stg_ap_ppp_ret (GHC version 6.8.3 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[2]: *** [build.stage.1] Abort trap make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 Intel Mac. I will also report bug. peace and happiness, -humasect

4 3

Re: GADTs and functional dependencies
by Wolfgang Jeltsch 24 Sep '08

24 Sep '08

Am Dienstag, 23. September 2008 19:07 schrieben Sie: > >> {-# LANGUAGE GADTs, MultiParamTypeClasses, FunctionalDependencies #-} > >> > >> data GADT a where > >> > >> GADT :: GADT () > >> > >> class Class a b | a -> b > >> > >> instance Class () () > >> > >> fun :: (Class a b) => GADT a -> b > >> fun GADT = () > > > > I’d expect this to work but unfortunately, using GHC 6.8.2, it fails with > > the > > > > following message: > >> FDGADT.hs:12:11: > >> Couldn't match expected type `b' against inferred type `()' > >> `b' is a rigid type variable bound by > >> the type signature for `fun' at FDGADT.hs:11:16 > >> In the expression: () > >> In the definition of `fun': fun GADT = () > > > > What’s the reason for this? Is there a workaround? Does this work in > > 6.8.3 or 6.10.1? > > This similar code using type families compiles in 6.8.3 and 6.9: > > data GADT a where > GADT :: GADT () > > type family F a > type instance F () = () > > fun :: GADT a -> F a > fun GADT = () Exactly. But this makes my code incompatible with GHC 6.6. :-( I thought, someone said that with the new typing machinery in GHC 6.10, more functional dependency programs are accepted because functional dependencies are handled similarly to type families (or something like that). Is this true? Since the type family version is okay, why shouldn’t the functional dependency version be okay? Best wishes, Wolfgang

2 2

Debian stable not supported?
by Yitzchak Gale 24 Sep '08

24 Sep '08

The Debian ghc6 package for the stable distribution is currently back at GHC 6.6 - not surprising given the way stable works at Debian. There is currently no backport of a more recent GHC to Debian stable. I need GHC 6.8 for a project to run on a production server. That means it will be running Debian stable. Unfortunately, the so-called "generic" Linux binary distribution package for GHC 6.8.3 does not work on the current, up-to-date Debian stable distribution because it is "too old". In my case, and I suspect for many people, the production server running stable is on a low-cost hosted VPS. That kind of platform doesn't have nearly enough memory and disk space to compile GHC. So even that is not an option. I know that in the past Haskell was used exclusively for research, but nowadays shouldn't it be possible to use Haskell also for production-quality projects? With help from Igloo and thetallguy on #ghc, for which I am grateful, I was finally able to get a working GHC 6.8.3 on my production server, but only after jumping through a lot of hoops. It involved setting up a Debian-stable-like environment in a chroot on another computer, building GHC there from source, and manually moving all of the appropriate files up to the server. Before I delete that chroot build environment - could it be useful for making GHC 6.8.3 available to others? If someone points me in the right direction, perhaps I could create a binary tarball and/or backport deb. Or at least record somewhere the basic steps of how to get a recent GHC in this situation. Thanks Yitz

5 5

GHC 6.8.3's source is unusable?
by Magicloud 24 Sep '08

24 Sep '08

Hi, I want to compile ghc on my office box, which does not have any binary ghc exist. So I followed http://hackage.haskell.org/trac/ghc/wiki/Building/Porting, "Porting GHC to a new platform" section. Well, this was what I got: (On target) $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target sytem type... i686-pc-linux-gnu Canonicalised to: i386-unknown-linux checking for ghc... no checking for ghc-pkg matching... no checking for ghc-pkg... no checking whether ghc has readline package... no checking for nhc... no checking for nhc98... no checking for hbc... no checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure: line 2660: -v0: command not found ./configure: line 2664: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory What does this mean!

4 4

Re: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready
by Chris Kuklewicz 23 Sep '08

23 Sep '08

I am cross-posting this message to several lists. I had learned the trick before the documentation was updated. It seems I have used a very unreliable trick. And the "use castToSTUArray" suggested alternative is a really poor one since I am not using arrays at all. Who can suggest a way to cast from Float to Word32 and Double to Word64 using ghc? The actual task is that I need to write out the Float as a little endian sequence of four bytes and also be able to read it back in. The writing and reading are done in Put and Get monads to ByteString (from the "binary" package). The alloca/poke/peek work around I have looks like castWord32ToFloat :: Word32 -> Float castWord32ToFloat x = unsafePerformIO $ alloca $ \p -> poke p x >> peek (castPtr p) castFloatToWord32 :: Float -> Word32 castFloatToWord32 x = unsafePerformIO $ alloca $ \p -> poke p x >> peek (castPtr p) The unsafeCoerce trick that is no longer working looks like: castWord64ToDouble :: Word64 -> Double castWord64ToDouble (W64# w) = D# (unsafeCoerce# w) castDoubleToWord64 :: Double -> Word64 castDoubleToWord64 (D# d) = W64# (unsafeCoerce# d) Any ideas? Or is the alloca trick the only way to do this? Chris Ian Lynagh wrote: > Hi Chris, > > On Sun, Sep 21, 2008 at 05:37:33PM +0100, Chris Kuklewicz wrote: >> Also, I tried two tricks: >> (D# x) <-> (W64# x) which works fine >> (F# x) <-> (W32# x) which produced garbage, so I had to replace it with >> alloca/poke/peek. > > This isn't supported, and I suspect is the cause of the -fasm problems. > > Please see > http://hackage.haskell.org/trac/ghc/ticket/2209 > for more details and suggested alternative. > > > Thanks > Ian >

3 2

Re: Instances and DoCon
by Serge D. Mechveliani 23 Sep '08

23 Sep '08

On Fri, Sep 19, 2008 at 08:17:12PM +0100, Ian Lynagh wrote: > On Tue, Sep 16, 2008 at 10:44:53AM +0100, Simon Peyton-Jones wrote: > > | > > | And still ghc-6.8.3 builds itself from source. > > > > I have no idea how -- Happy has been needed for some time. Maybe someone else does. > > It's not meant to be needed for building from a source tarball. > This should be fixed now. Dear GHC team, can you, please, provide such GHC source distributives which require possibly smaller set of programs for the user to separately pre-install? For example, do not require of the user to install Alex, Happy and Cabal. Because we write applications in Haskell. For example, the user needs to program algebra by using some CA library written in Haskell. One needs to install GHC -- and the simpler the better. In this situation, it is bad to force him to think of what is Alex or Happy, and where to find them and how to install. The least hindrance in installation makes some users to reject the tool: "Oh! looks messy, suspicious thing. I tried the binary, but it reports of wrong libarary versions. I have already spent one hough! Also these pure functional languages look restrictive ... Let me better try the Foo system". Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2