- Glasgow-haskell-users

Overlapping instances vs. Haskell98 Report [was: How to disable warning for "export item 'module ...' exports nothing"?]
by Sean Leather 15 Aug '08

15 Aug '08

Ross Paterson wrote: > On Fri, Aug 15, 2008 at 04:17:44PM +0200, Sean Leather wrote: > > module A where > > class A t where > > a :: t > > > > module B where > > import A > > instance A Int where > > a = 0 > > a0 :: Int > > a0 = a > > > > module C where > > import A > > instance A Int where > > a = 1 > > a1 :: Int > > a1 = a > > > > module Main where > > import A > > import B > > import C > > main = do putStrLn $ "a0=" ++ show a0 > > putStrLn $ "a1=" ++ show a1 > > > > This works, because of the way the instances are used. While overlapping > > instances are imported into Main, they are not used in Main. > > Then that is a GHC bug. Haskell 98 Report 4.3.2: "A type may not be > declared as an instance of a particular class more than once in the > program." > That's interesting. So, maybe there should be some language extension or warning (with associated -fno-warn) for this in GHC. Personally, I prefer the way it's done now. (I guess that's obvious, considering I'm developing a library that will take advantage of it. ;) ) But it makes sense that instances are only looked up when needed, instead of globally tracked. Sean

2 1

How to disable warning for "export item 'module ...' exports nothing"?
by Sean Leather 15 Aug '08

15 Aug '08

Hi, I have a module A that re-exports module B, and module B contains only class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do. Thanks, Sean

3 12

How to produce a statically linked binary with GHC?
by Nicola Squartini 15 Aug '08

15 Aug '08

It seems that the -static flag serves a different purpose: according to the GHC manual it forces the compiler use the static Haskell libraries, but the resulting binary is still dynamically linked to the C libraries. What is the correct flag to create a static binary? Thanks Best Regards Nicola

5 8

Re: Orphan Instances
by Yitzchak Gale 12 Aug '08

12 Aug '08

<Moving this side point to the ghc users list...> Ashley Yakely wrote: >> What is an orphan instance, and why do we care about them? Simon Peyton-Jones wrote: > They are documented in the GHC manual > http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilatio… Thanks for the nice explanation there. Since you brought it up, though, the explanation might be made even clearer with two small changes: 1. The term "instance head" is used throughout the explanation, beginning already with the second paragraph ("the head of the instance..."). However, that term is only defined near the very end '(the part after the "=>")'. For those who do not already know the surprise ending, this makes the explanation read rather like a mystery story. 2. I believe that the text "by setting a = Int" was meant to be "by setting a = T". Thanks, Yitz

2 1

RE: Version control systems
by Eric 12 Aug '08

12 Aug '08

A metacomment: As a lurker, and a reader of other languages' mail groups, I just wanted to complement you GHC folks on the quality of your discussion. You're discussing an issue that people clearly have strong opinions about, yet you've all remained polite and respectful and kept the signal-to-noise ratio of the discussion high, unlike what I see on some the mail groups of some other languages. It's a pleasure reading even your disagreements. --Eric

1 0

Faster checkout times under Git
by Don Stewart 12 Aug '08

12 Aug '08

Eric Mertens kindly did some experiments on the various git repos, and servers, and approaches to serving. * We're looking at >45 mins for a full history darcs get of ghc, over http, from darcs.haskell.org. * git clone of full ghc over http, from darcs.haskell.org, completes in the range of 6-7 minutes (roughly 150KiB/s) * git clone over git protocol, using github's bandwidth, completes in 2.1 minutes. (roughly 560KiB/s) So that indicates a significant improvment by switching to the git:// server protocol. Can we get that on darcs.haskell.org? In general git is doing a good job here addressing slow 'darcs get ' times, which are now way way down. This will make life easier for some of us. Mirroring automatically to github could also address some of our redundancy concerns. -- Don

2 1

Confusing flags for RULES in GHC
by Simon Peyton-Jones 11 Aug '08

11 Aug '08

Friends The use of flags to control rewrite rules in GHC is very confusing. Several bug reports arise from this. There is a summary here: http://hackage.haskell.org/trac/ghc/ticket/2497 The final comment is a proposal, which I append below. This email is just to allow others to comment on the proposed change. It's all minor and tiresome, but I don't want to change it and then find it's still awkward. NB: please read the whole ticket if you want to comment on these proposals. And add your comments to the ticket. Simon * Do not add -XRewriteRules. A RULE is in a pragma, and so is silently ignored by other compilers anyway. Other pragmas like SPECIALISE do not have a language extension flag. They will generate errors if they are plain wrong (e.g. variables out of scope). But adding a language flag would be inconsistent. * Inside a RULE, switch on the forall-as-keyword in the lexer, unconditionally. Simon M will do this, and send a patch to Simon PJ for validation. * Merge the -XScopedTypeVariables and -XPatternSignatures flags. Distinguishing them isn't senseless, but it's jolly confusing. * Inside a RULE, switch on -XScopedTypeVariables unconditionally. * Change -frewrite-rules to -fuse-rewrite-rules; deprecate the former.

1 0

git and sync-all: Why not merge in libraries?
by Bryan Donlan 07 Aug '08

07 Aug '08

Hi all, With the upcoming switchover to git, has any thought gone into merging in the libraries into the main ghc tree (eliminating the need for a 'git-all')? git can merge two histories with no common ancestor, so no history would be lost - though you'd have to ask greater gurus than I the proper procedure. It's been done a few times on git itself to fold in externally developed tools. As I understand it, you could even continue development of the libraries on a seperate tree, as long as you don't try merging changes on ghc.git to $library.git, unless you filter out the GHC-only changes first somehow (merging $library.git back into ghc.git, as I understand it, should work...). Not sure if I'm missing something here, or if it's impractical for some reason... Thanks, Bryan Donlan

2 1

IRC meeting
by Simon Marlow 06 Aug '08

06 Aug '08

IRC Meeting today at 1600 UK time as usual (1500 UTC, 0800 PDT, 1100 EDT). A couple of suggestions for topics; - HEAD stability (re previous disccusion on cvs-ghc) - mechanics of the git switchover Cheers, Simon

1 0

Re: Version control systems
by Felix Martini 06 Aug '08

06 Aug '08

> and Windows support is less of an issue: git appears to work reasonably well on Windows these days. Congratulations on the switch, but isn't the decision a bit premature? I have read the log of last week's GHC meeting on IRC and nobody seemed to know if Git runs well on Windows with a large project like GHC. I also prefer Git to Darcs or Mercurial on Linux, but this rather quick decision makes it look like Windows support of GHC is an afterthought. Regards, Felix

3 2