- Glasgow-haskell-users

Making Windows executables...
by Juan Carlos Arevalo Baeza 28 Aug '05

28 Aug '05

When compiling a haskell program under Windows, is there any way to compile it as a GUI program instead of a console program? JCAB

3 4

RE: Functional Dependencies
by Simon Peyton-Jones 19 Aug '05

19 Aug '05

| > class C a b | a -> b | > instance C Int Bool | > | > f :: forall a. C Int a => a -> a | > f x = x | > | > GHC rejects the type signature for f, because we can see that 'a' *must | > be* Bool, so it's a bit misleading to universally quantify it. | | Ok, maybe this is a reasonable choice. But why does the attached program work? | ghci presents a unique type for the universal quantified function 'eight': | | *Add> :t eight | eight :: Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ Zero))))))) >From the instance declaration instance Fib Zero (Succ Zero) we get the improvement rule Fib Zero a ==> a=(Succ Zero) We get a similar rule from instance Fib (Succ Zero) (Succ Zero) But the instance declaration instance (Fib n fib_n, Fib (Succ n) fib_s_n, Add fib_n fib_s_n sum ) => Fib (Succ (Succ n)) sum Fib Zero a gives only Fib Zero a ===> exists b. b=a which does nothing useful. So when GHC sees the type signature, it's quite happy. No improvement takes place. If you compile Fib with -ddump-types you'll see it gets the type you specify. HOWEVER, when you say ":t eight", GHC does not simply report the type of "eight". You can type an arbitrary expression there (e.g. ":t (reverse "hello")"). So GHC typechecks the expression "eight". So it instantiates its type, and then tries to solve the constraint (Fib (Succ (Succ...)) n). Now it must use the instance declarations to simplify it, and in doing so that exposes more constraints that do force n to be the type you get. I agree this is desperately confusing, and I'm not saying that GHC is doing the Right Thing here; but I wanted to explain what it is doing. Functional dependencies are very slippery. I do not think their behaviour in GHC is necessarily best, nor is their exact behaviour specified anywhere, but I do think the behaviour is consistent. My current belief is that fundeps are too slippery to be given to programmers at all. They are not a good way to express type-level computation. Perhaps associated types might be a better way to express this stuff (see my home page). Simon

2 1

RE: Functional Dependencies
by Simon Peyton-Jones 17 Aug '05

17 Aug '05

You raise a vexed question, which has been discussed a lot. Should this typecheck? class C a b | a -> b instance C Int Bool f :: forall a. C Int a => a -> a f x = x GHC rejects the type signature for f, because we can see that 'a' *must be* Bool, so it's a bit misleading to universally quantify it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Dirk Reckmann | Sent: 21 July 2005 10:30 | To: glasgow-haskell-users(a)haskell.org | Subject: Functional Dependencies | | Hello everybody! | | I wanted to have some fun with functional dependencies (see | http://www.cs.chalmers.se/~hallgren/Papers/wm01.html) and tried some | examples from this paper as well as some own experiments. The idea is to use | the type checker for computations by "abuse" of type classes with functional | dependencies. | | The example in the attached file is taken from the above paper. Due to the | functional dependencies, I expected the type of seven to be uniquely | determined to be (Succ (Succ (Succ ...))), i. e. seven, but ghc (version 6.4) | gives me following error message: | | Add.hs:14:0: | Couldn't match the rigid variable `a' against `Succ s' | `a' is bound by the type signature for `seven' | Expected type: Succ s | Inferred type: a | When using functional dependencies to combine | Add (Succ n) m (Succ s), arising from the instance declaration at | Add.hs:11:0 | Add (Succ (Succ (Succ Zero))) (Succ (Succ (Succ (Succ Zero)))) a, | arising from the type signature for `seven' at Add.hs:13:0-77 | When generalising the type(s) for `seven' | | However, using the definition of Add to define Fibonacci numbers does work, | and a similar function declaration can be used to compute numbers by the type | checker. | | The same definition of Add works in Hugs... | | So, is this a bug in ghc, or am I doing something wrong? | | Thanks in advance, | Dirk Reckmann

4 7

RE: C--
by Simon Peyton-Jones 17 Aug '05

17 Aug '05

| I am trying to understand the role of cmm files in the current GHC | compiler build process (I am guessing, they have replaced .hc files | like PrimOps and AutoApply). Yes, that's exactly right. | They are compiled by the stage1 compiler. Is ability to compile cmm | preserved in the compiler finally built at stage3 and installed? Yes it is. | What compiler flags are available for cmm files compilation? The | User's guide says nothing specific. Are -E, -C, -S available (along | with -c and -fvia-c seen in the nightly build log)? I think -C and -S are. I'm not sure about -E. Try it! You're right that it ought to say. I suspect that the whole "compile Foo.cmm" route is ill-described in the manual; even .cmm language (which is only a subset of C--) isn't described. Reason: we think of it as an internal thing. But it's fine for you to use it, and if it becomes useful to others we should document it better. If you can suggest specifically what would be helpful to you, and specifically where in the manual, and better still provide some specific words, I'll gladly paste them in. Simon

1 0

Re: [loeh@iai.uni-bonn.de: Re: -odir behaviour change in 6.4.1?]
by Isaac Jones 16 Aug '05

16 Aug '05

"Andres Loeh" <loeh(a)iai.uni-bonn.de> writes: > Hello again, (snip) Simon Says: >> Yes, this change was made for consistency (someone else reported the >> breakage). I've also patched Cabal, so perhaps you're using a version >> from before the fix? > > I must be doing something wrong, then. (snip) > /usr/bin/ghc -odir dist/build/foo/foo-tmp/foo -hidir dist/build -c foo/foo.c That's the wrong part. > /usr/bin/ghc -odir dist/build/foo/foo-tmp -hidir dist/build/foo/foo-tmp -o dist/build/foo/foo -hide-all-packages --make -i -i. -package base-1.0 dist/build/foo/foo-tmp/foo/foo.o Main.hs > Chasing modules from: Main.hs > Compiling Main ( Main.hs, dist/build/foo/foo-tmp/Main.o ) > Linking ... > gcc: dist/build/foo/foo-tmp/foo/foo.o: No such file or directory > > The file foo.o is at dist/build/foo/foo-tmp/foo/foo/foo.o ... Build.hs has this logic: odir | versionBranch ghc_vers >= [6,4,1] = pref | otherwise = pref `joinFileName` dirOf c -- ghc 6.4.1 fixed a bug in -odir handling -- for C compilations. which is good, but it only does that for libraries, not executables. Damn. This needs to get refactored to share code. I think I fixed this. Should be in the latest darcs and CVS. Andres, can you try this and let me know? peace, isaac

1 0

C--
by Dimitry Golubovsky 12 Aug '05

12 Aug '05

I am trying to understand the role of cmm files in the current GHC compiler build process (I am guessing, they have replaced .hc files like PrimOps and AutoApply). They are compiled by the stage1 compiler. Is ability to compile cmm preserved in the compiler finally built at stage3 and installed? What compiler flags are available for cmm files compilation? The User's guide says nothing specific. Are -E, -C, -S available (along with -c and -fvia-c seen in the nightly build log)? -- Dimitry Golubovsky Anywhere on the Web

1 0

RE: -odir behaviour change in 6.4.1?
by Simon Marlow 11 Aug '05

11 Aug '05

On 10 August 2005 00:05, Andres Loeh wrote: > Is this change in behaviour between ghc-6.4 and ghc-6.4.1 desired: > > ~/trans $ ls foo > foo.c > ~/trans $ ghc-6.4 -odir foo -c foo/foo.c > ~/trans $ ls foo > foo.c foo.o > ~/trans $ rm foo/foo.o > ~/trans $ ls foo > foo.c > ~/trans $ ghc-6.4.1.20050804 -odir foo -c foo/foo.c > ~/trans $ ls foo > foo foo.c > ~/trans $ ls foo/foo > foo.o > > It seems to break cabal-1.1.1, in the case that I have something > like > > c-sources: foo/foo.c > > in my .cabal file ... Yes, this change was made for consistency (someone else reported the breakage). I've also patched Cabal, so perhaps you're using a version from before the fix? Cheers, Simon

2 1

6.4.1 release candidate testing on Solaris
by Geisler, Tim (EXT) 11 Aug '05

11 Aug '05

ghc-6.4.1.20050806 (and before ghc-6.4.1.20050731) built successfully on Solaris (Sparc). bash-2.05$ uname -a SunOS kleopatra 5.9 Generic_118558-04 sun4u sparc SUNW,Sun-Fire-V240 bash-2.05$ gcc -v Reading specs from /export/home/haskells/geisler/sw/lib/gcc/sparc-sun-solaris2.9/3.4.4/spec s Configured with: ./configure --prefix=/export/home/haskells/geisler/sw --with-ld=/export/home/haskells/geisler/sw/bin/ld --with-as=/export/home/haskells/geisler/sw/bin/as Thread model: posix gcc version 3.4.4 bash-2.05$ ld -v GNU ld version 2.16 bash-2.05$ as -v GNU assembler version 2.16 (sparc-sun-solaris2.9) using BFD version 2.16 ghc was configured with: ./configure --prefix=/export/home/haskells/geisler/sw --disable-opengl --disable-glut --disable-openal To build ghc-6.4.1.20050806, I used ghc-6.4.1.20050731 which was built with Christian Maeder's binary distribution for Solaris (http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris 2.tar.bz2) from June 2005. I was able to build all our Haskell code. Some first tests were successful. Tim

2 1

[ ghc-Feature Requests-1256514 ] Declare large amounts of constant data
by SourceForge.net 11 Aug '05

11 Aug '05

Feature Requests item #1256514, was opened at 2005-08-11 11:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1256514&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Nobody/Anonymous (nobody) Summary: Declare large amounts of constant data Initial Comment: Simon Marlow wrote in Bug#635718: "It is true that GHC doesn't have a good way to declare large amounts of constant data. This is a shortcoming, but not a bug (please by all means submit a feature request)." Submitting as requested:) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1256514&group_…

1 0

ANN: C->Haskell version 0.14.3 "Travelling Lightly"
by Manuel M T Chakravarty 10 Aug '05

10 Aug '05

I like to announce version 0.14.3 of C->Haskell, which brings the following advances over 0.14.1: * gcc's asm construct is supported, which is apparently important for some libraries on Mac OS X (thanks to Duncan Coutts for the patch); * C->Haskell supports cross compilation (see details below); [NB: C->Haskell now generates completely portable Haskell code (needs only H98 + FFI) and can target C compilers on platforms that cannot build C->Haskell itself; eg, PalmOS. In particular, C->Haskell generated bindings are suitable for nhc98 and Hugs, too.] * hierarchical modules syntax can be used in import hooks (again thanks to Duncan for the patch); and * two new built-in translation functions "upcaseFirstLetter" and "downcaseFirstLetter" are supported to generated suitable Haskell names from C names (eg, for variants of enums). Source code is available as a tar ball from http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ or via Darcs (binary packages may appear later). Happy Hacking, Manuel -=- Cross compilation -=- C->Haskell needs to take system-specific parameters of the C compiler used to compile the libraries for which an interface is generated into account (most notably when bitfields are used in this library). By default C->Haskell uses the conventions of the C compiler that was used to build C->Haskell itself. From this version, C->Haskell accepts the --platform=PLATFORM flag that enables the explicit specification of the target platform. This works only for platforms that are in C->Haskell's platform specification database. At the moment, that's only i686-pc-linux-gnu and m68k-palmos. However, it is very easy to determine the platform specification for any platform on which you can build C->Haskell: Just invoke it as `c2hs --version' and it will tell you. If you send me the output of `c2hs --version', I'll happily add it to the database. (If you'd like to target a platform on which you cannot build C->Haskell, such as an embedded system, let me know.)

1 0