- Glasgow-haskell-users

Encoding Lists with Lengths by Type Family
by Shin-Cheng Mu 11 Dec '07

11 Dec '07

Hi, I understand that the type family is still an experimental feature in GHC. This is just a confirmation whether it is a bug, or is what the designers intended. I am curious how much "dependent type" programming I can emulate using GADT and type family. Therefore I started with the typical "list with length" example. List a n is a list of elements a and length n encoded by singleton types Zero and Suc, as was done in the paper Towards Open Type Functions for Haskell: > data Zero = Zero > data Suc a = Suc a > data List a n where > Nil :: List a Zero > Cons :: a -> List a n -> List a (Suc n) Concatenation effortlessly type checks! > cat :: List a m -> List a n -> List a (Plus m n) > cat Nil y = y > cat (Cons a x) y = Cons a (cat x y) However, I was not able to convince GHC that the following function revcat, list reversal using an accumulating parameter, is type correct: > revcat :: List a m -> List a n -> List a (Plus m n) > revcat Nil y = y > revcat (Cons a x) y = > subst incAssocL (revcat x (Cons a y)) In the recursive case, (Cons a x) has type List a (Suc m) and y has type List a n. The recursive call to revcat is supposed to yield a list of type: List a (Plus m (Suc n)) while we want the return type to be List a (Plus (Suc m) n) Therefore I shall provide a conversion proving that they are actually the same thing. Currently I give the types only and will think about how to implement them later: > subst :: (m -> n) -> List a m -> List a n > subst = undefined > incAssocL :: Plus m (Suc n) -> Plus (Suc m) n > incAssocL = undefined However, GHCi (run with options -XTypeFamilies -XGADTs) gave me the following error message: Couldn't match expected type `Plus n3 n2' against inferred type `Plus m n1' Expected type: Plus m (Suc n1) -> Plus (Suc n3) n2 Inferred type: Plus m (Suc n1) -> Plus (Suc m) n1 In the first argument of `subst', namely `incAssocL' In the expression: subst incAssocL (revcat x (Cons a y)) For some reason GHC wanted me to return the more general type Plus (Suc n3) n2 where n2 and n3 are fresh, rather than unifying n2 with m and n2 with n. Why is that? sincerely, Shin

2 1

New woes regarding ghc-6.8.1 on FreeBSD-amd64
by Wilhelm B. Kloke 11 Dec '07

11 Dec '07

Some days ago I announced having success in porting ghc-6.8.1 to FreeBSD-7.0-amd64. As the compiler seemed to be able to compile itself, I was confident to make the binary package available to the public. Now I have found out that the port is rooten in a very weird way. >From the files in testsuite (6.6.1) it has 4707 expected passes vs. 669 unexpected failures. Among the most unexpected of these is the failure of arith003 (conversions between Int and Integer near 64bit boundary). It seems there is still some 32/64-bit confusion left from the building process. Still worse is, that any attempt to use the partially usable compiler as bootstrap tool fails for some reasons. On a freshly configure 6.8.1 tree (with ./configure --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib ) the build process fails at libraries/base/Control/Concurrent.hs because gmp.h is not found by ghc-inplace I fixed this by copying /usr/local/include/gmp.h to ghc-6.8.1/includes. This is, of course, a risk of confusing the 32/64bit version of this library. Anyway, the resulting compiler in stage2/ghc-6.8.1 dumps core. Perhaps I can get better results, if I use the most conservative settings possible for stage1 build, but I have no idea what they are. The recommended porting process (via .hc files) fails, too. I am going to make a separate bug report about this. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key

1 0

Re: HUnit 1.2.0.0 on 6.8.1 vs 1.1.1 on 6.6.1
by Greg Fitzgerald 11 Dec '07

11 Dec '07

> >> > "abc" @=? "efg" > >> Loading package HUnit-1.2.0.0 ... linking ... done. > >> *** Exception: (unknown) > > On Dec 3, 2007 7:23 AM, Ian Lynagh <igloo(a)earth.li> wrote: > > This is caused by a change in the HUnit library, from > > assertFailure msg = ioError (userError (hunitPrefix ++ msg)) > > to > > assertFailure msg = E.throwDyn (HUnitFailure msg) I've had no luck contacting Dean Herington using the email address posted on the HUnit page. > They just use the latest version in the darcs repositories at the time that they are built Sounds like this is the first case where the latest version isn't a stable one (Go Haskell!). Is it much trouble for package maintainers to package GHC with HUnit.1.1.1? To keep it simple, maybe there should be an HUnitStable branch where 1.1.1 is the latest version? Thanks, Greg

2 1

GHC 6.8.2, Haddock not finding std libs
by Greg Fitzgerald 11 Dec '07

11 Dec '07

> Please test as much as possible One difference between 6.8.1 and 6.8.2 that I see is in running "runhaskell Setup.hs haddock" with Haddock 0.8 on Windows XP. Haddock is no longer able to resolve the names from the standard libraries. Running Haddock for Xyz-0.1... Warning: Xyz: the following names could not be resolved: FilePath Show Eq String Maybe Bool Char Int Thanks, Greg

3 4

Re: type equality symbol
by Johannes Waldmann 10 Dec '07

10 Dec '07

On Fri, 7 Dec 2007, Manuel M T Chakravarty wrote: > The problem is that Haskell 98 already messed that up. > If type functions are to use lower-case letters, [...] Yes. The broken thing is that the upper/lower case distinction has syntactic importance in the language definition at all. I guess this was introduced to avoid writing out some declarations. This is a bad design goal, especially so for a declarative language. Reminds me of ancient Fortran using the first letter of an identifier for implicit typing (I .. N for integer, others for real). Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 2

Strange compilation behavior
by Chad Scherrer 10 Dec '07

10 Dec '07

Hello, I'm using ghc 6.6.1 under Ubuntu Gutsy on a Pentium 4 machine, and I was working to get some code running in an acceptable time. I was surprised to find that turning on profiling switches made the code run over 40x faster! Here's the first run, using ghc --make -O2: 88.03user 0.08system 1:28.16elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+13517minor)pagefaults 0swaps And with ghc --make -O2 -prof -auto-all: 2.33user 0.07system 0:02.41elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+17712minor)pagefaults 0swaps Otherwise everything is the same! Is this something anyone else has run into? I'm not sure if it might have been fixed in 6.8.1, but something funny is going on here. Thanks, Chad

3 2

HUnit 1.2.0.0 on 6.8.1 vs 1.1.1 on 6.6.1
by Greg Fitzgerald 08 Dec '07

08 Dec '07

On Windows, HUnit's assertions are not working - trace below in ghci 6.8.1and 6.6.1. Can others reproduce? Is this the right place to report bugs? Should I confirm a bug here and then create a ticket, create a ticket and that's it, or just mention it here and someone else creates a ticket? GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. > :m Test.HUnit > "abc" @=? "efg" Loading package HUnit-1.2.0.0 ... linking ... done. *** Exception: (unknown) ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. > :m Test.HUnit > "abc" @=? "efg" Loading package HUnit-1.1.1 ... linking ... done. *** Exception: user error (HUnit:expected: "abc" but got: "efg") Thanks, Greg

3 4

ANNOUNCE: GHC 6.8.2 Release Candidate
by Ian Lynagh 07 Dec '07

07 Dec '07

We are pleased to announce the Release Candidate phase for GHC 6.8.2. Snapshots beginning with 6.8.1.20071206 are release candidates for 6.8.2 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.1.20071206-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.1.20071206-src-extralib… Only the first of these is necessary. The "extralibs" package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team

3 2

fundeps help
by Ganesh Sittampalam 07 Dec '07

07 Dec '07

Hi, I'm trying to understand what fundeps do and don't let me do. One particular source of confusion is why the following program doesn't typecheck: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} module Fundeps where class Dep a b | a -> b, b -> a conv :: (Dep a b1,Dep a b2) => b1 -> b2 conv = id {- end of program -} It seems as if inferring that b1 = b2 is precisely what "improvement" is about, but I'm not really sure when GHC actually applies that. Is there any documentation of that? I've read Mark Jones' paper, the haskell-prime wiki entry about Fundeps and the GHC manual but am still rather lost. Cheers, Ganesh

9 18

Problems building and using ghc-6.9
by Daniel Fischer 07 Dec '07

07 Dec '07

Hi, so today I built ghc-6.9.20071124. First, make died because HsColour version >= 1.8 was needed, couldn't determine the version. I had HsColour 1.6, got myself 1.8, built and installed. make died again, same problem. I added ("v", Version) to the optionTable in HsColour.hs and it worked :) Then I tried to build zlib-0.4.0.1: $ runghc ./Setup.hs configure --user --prefix=$HOME Configuring zlib-0.4.0.1... Setup.hs: At least the following dependencies are missing: base >=2.0&&<2.2 ??? okay, there was something with flag bytestring-in-base, removed that, so that build-depends was base < 2.0 || >= 2.2, bytestring >= 0.9, then $ runghc ./Setup.hs configure --user --prefix=$HOME Configuring zlib-0.4.0.1... Setup.hs: At least the following dependencies are missing: base <2.0||>=2.2, bytestring >=0.9 but: $ ghc-pkg list /home/dafis/lib/ghc-6.9.20071124/package.conf: ALUT-2.1.0.0, Cabal-1.3, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, array-0.1, base-3.0, bytestring-0.9, cgi-3001.1.5.1, containers-0.1, directory-1.0, fgl-5.4.1.1, filepath-1.1, (ghc-6.9.20071124), haskell-src-1.0.1.1, haskell98-1.0.1, hpc-0.5, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0, old-time-1.0, packedstring-0.1, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0, process-1.0, random-1.0, readline-1.0.1, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2, time-1.1.2.0, unix-2.2, xhtml-3000.0.2.1 and in stringsearch-0.2: $ runghc ./Setup.lhs configure --user --prefix=$HOME Configuring stringsearch-0.2... Setup.lhs: At least the following dependencies are missing: base -any What's going on?? How can I build packages with ghc-6.9? Or do I have to go back to 6.8.1? Thanks, Daniel

2 1