- Glasgow-haskell-users

RE: Character index vs Column number in GHC error messages
by Bayley, Alistair 31 Aug '05

31 Aug '05

> From: Krasimir Angelov [mailto:kr.angelov@gmail.com] > > The difference comes from the tab > characters which can have different width depending from the editor > settings. For such reason all compilers, which I am aware of, display > the character index instead of column number. ... GHC displays the > column number instead and this confuses the editors. Dude! Don't use tabs :-) ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

Character index vs Column number in GHC error messages
by Krasimir Angelov 30 Aug '05

30 Aug '05

Hello, Guys Quite recently GHC was changed to display the column number as well as the line number in all error messages. This is useful feature but I found the following difficulty with using it. All text editors that have built-in support for compilers, expect to find the line number in the reported error messages. Some of them support column number as well, but actually this isn't the column number but the character index in the current line. The difference comes from the tab characters which can have different width depending from the editor settings. For such reason all compilers, which I am aware of, display the character index instead of column number. I tried this with C#, Visual Basic and GNU CPP. GCC, Sun's Java compiler and Visual C++ compiler are displaying only the line number. Using the character index the editor can unambiguously find the exact position where the error is independently from the current tab setting. GHC displays the column number instead and this confuses the editors. At least I tried this with Visual Studio and TextPad editor. I have modified the GHC parser so that it displays the character index instead of column number, but I am curious whether this is the preferred behaviour of the other compilers/editors. Any thoughts are appreciated. Cheers, Krasimir

1 0

Automatically derived instances
by Juan Carlos Arevalo Baeza 29 Aug '05

29 Aug '05

(BCC'ing the GHC bugs list) It seems like there's something very funky going on with GHC (6.4) and automatically deriving instances. Consider this code: ---8<-------------------------------------- 1: class MyClass a 2: 3:instance MyClass a => Show a 4: 5:newtype Type1 = Type1 { unType1 :: Int } deriving (Show) 6: 7:main = putStrLn $ show $ Type1 4 ---8<-------------------------------------- If you try to compile this, you get: ---8<-------------------------------------- Overlapping instances for Show Int arising from the 'deriving' clause of a data type declaration at Test.hs:5:8 Matching instances: Test.hs:3:0: instance (MyClass a) => Show a Imported from GHC.Show: instance Show Int When deriving the `Show' instance for type `Type1' ---8<-------------------------------------- Weird error. I haven't even declared an instance of MyClass! If I change line 5 to "deriving (MyClass), I get: *** Exception: stack overflow Sounds like a compiler bug to me. If I comment out line 3 and leave "deriving (Show)", it all works as expected. So... what's exactly the purpose of omitting the where-part of an instance declaration? It is supported, and it is even shown in code in the Haskell 98 report, but I failed to find any place in the whole document where it was described. Same thing for GHC's documentation. My purpose here was to do group classes for deriving like so: ---8<-------------------------------------- class MyNum a instance MyNum a => Eq a instance MyNum a => Ord a instance MyNum a => Show a instance MyNum a => Enum a instance MyNum a => Num a instance MyNum a => Real a instance MyNum a => Integral a instance MyNum a => Bits a instance MyNum a => Storable a -- Too long?... newtype ID = ID { unID :: WORD } deriving (Eq, Ord, Show, Enum, Num, Real, Integral, Bits, Storable) newtype ID = ID { unID :: Int } deriving (MyNum) ---8<-------------------------------------- I guess that's not doable? JCAB

3 3

Profiling under 6.4.1 and Solaris segfaults
by Nils Anders Danielsson 29 Aug '05

29 Aug '05

Running a simple Hello World program compiled with a GHC 6.4.1 snapshot (20050820) and profiling turned on (-prof -auto-all) under Solaris results in a segfault. The core dump is similar to a core dump posted earlier (http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg04621.html) (gdb) where #0 0x0003df8c in EnterFunCCS () #1 0x0004a714 in stg_PAP_info () #2 0x00045538 in schedule () #3 0x00045ff8 in waitThread_ () #4 0x00045f48 in scheduleWaitThread () #5 0x0004258c in rts_evalLazyIO () #6 0x0003bea8 in main () The other core dump was due to not compiling the entire program with profiling turned on. However, the profiling libraries are installed, so I see no reason why that should be the case now. On the other hand, when I compile with -fno-implicit-prelude (and main = main), I don't get a core dump. Have other Solaris users experienced something similar? I don't have any problems with the Linux snapshot from the same day. -- /NAD

1 0

Re: "#!..." (Re[2]: cabal configure screw-up)
by Seth Kurtzberg 28 Aug '05

28 Aug '05

Frederik Eaton wrote: >>But it isn't running "in a unix emulation environment." cygwin is >>simply _not_ such an environment. The program is started by a different >>shell, but that is _not_ an emulation environment. >> >> > >Is it an elephant? A tree? > > I guess the most accurate way to describe it is that it tries to emulate the _development_ environment of UNIX. It has gnu make and various other utilities and shells compiled to run under win32. So you can build things that rely on shell scripts, because the shell scripts are executed by either (1) a shell, which knows the conventions about how to execute scripts or (2) the make utility, which similarly has been forced to behave such that makefiles that rely on scripting still work. This does not, unfortunately, extend to the run time environment. That's why I said it isn't an emulation environment. A program that is executing is not different in any way from any other native win32 program that is executing. A program could be set up to check whether it was started from a UNIX like shell, by querying it's parent process, but obviously this has problems. O/S functions, such as the ones that allow one process to execute another process, are unmodified. There is no library that intersperses itself between the process and the O/S. So there is really no way to change the O/S behavior, specifically with regard to running scripts, but more generally in any way. >Frederik > > >

1 0

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

27 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 15 Aug '05

15 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