- Glasgow-haskell-users

Hiding module *exports*
by Tom Murphy 27 Oct '14

27 Oct '14

(Not to be confused with the "hiding import behavior" discussion also going on) -- Currently, I'm able to write "module Foo where" to export everything defined in Foo. If, though, I add to the module some definitions which I don't want to export... data Lockbox = MkLockbox Int internalFunction = ... ...I then have to explicitly enumerate everything that I *do* want the module to export, and add to that list each time I add to the module. I propose that instead, we're able to simply say what we mean: module Foo hiding (Lockbox(MkLockbox), internalFunction) where I think its semantics are immediately clear to the reader. There's a little bit of bikeshedding that needs to happen (e.g. is "hiding (Foo(..))" sufficient to hide the type Foo and not just its constructors), but are people +1 on this? I've frequently wanted this behavior. Tom

9 10

ghci balkiness on OS X?
by Evan Laforge 25 Oct '14

25 Oct '14

On my OS X, if I load a couple hundred modules into ghci as bytecode, text entry gets balky and laggy. So e.g. if I hold down a key, the letters will stream in but have frequent hiccups. This seems to adversely affect haskeline as well, such that, using vi mode, sometimes ^[ to move to command mode will be lost, or it will spontaneously go to insert mode, or ^[ followed by 'h' will be just beep and remain in insert mode. If I load most of the modules compiled, this doesn't happen, or at least is not nearly so bad. It doesn't seem to be due to background work by ghci or anything, because it doesn't matter how long I wait after loading the modules. My previous random guess was that increased memory use made the GC work more, and my pauses were due to major collections. But when I try on linux, ghci remains responsive no matter how many modules I load, so maybe it's an OS X only problem. Do any other OS X users see this effect?

3 3

Hiding import behaviour
by Malcolm Gooding 24 Oct '14

24 Oct '14

With the prelude changes that people have been discussing recently I've been wondering is there any reason why importing an identifier explicitly and unqualified doesn't automatically hide any implicit imports of the same identifier? Specifically I'm wondering about cases where you've imported an identifier explicitly from only one module, like this: module Foo (x, ...) where { ... } module Bar (x, ...) where { ... } import Bar import Foo (x) Even if you needed a pragma to enable it I can't think of any sensible reason why that shouldn't be equivalent to: import Bar hiding (x) import Foo (x) I don't know much of GHC's internals, but it seems like a pretty minimal change. Typing rules remain the same; explicit imports just shadow implicits. So importing multiple identifiers both implicitly or both explicitly would remain ambiguous.

12 30

Type checker plugins
by Adam Gundry 23 Oct '14

23 Oct '14

Hi folks, Those of you at HIW last week might have been subjected to my lightning talk on plugins for the GHC type checker, which should allow us to properly implement nifty features like units of measure or type-level numbers without recompiling GHC. I've written up a wiki page summarising the idea: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker Feedback is very welcome, particularly if (a) you have an interesting use for this feature or (b) you think this is a terrible idea! Thanks, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 11

Re: GHC 7.4.2 on Ubuntu Trusty
by Yitzchak Gale 22 Oct '14

22 Oct '14

I wrote: >> How do I get a working GHC 7.4.2 on Trusty? Thanks to all for the suggestions. Daniel Trstenjak wrote, off-list: > I can only recommend: https://launchpad.net/~hvr/+archive/ubuntu/ghc Thanks Daniel! I hadn't looked at Herbert's ppa for a while. Despite the comments, which say it is only updated for precise but should also work for trusty, the ppa actually *is* updated for trusty now. This is trivially simple to use and worked great, so that's what I ended up using. But still - something really really needs to be done about GHC portability. This thread makes it clear what a mess we have inherited from the days when GHC was primarily a research compiler. Let's face it - GHC is now also a serious production compiler, and this urgently needs to be cleaned up. Thanks, Yitz

1 0

GHC 7.4.2 on Ubuntu Trusty
by Yitzchak Gale 22 Oct '14

22 Oct '14

In order support some older software that we released, we need to get a working GHC 7.4.2 on Ubuntu Trusty. We currently have GHC 7.8.3. The binary tarball for GHC 7.4.2 does not install on Trusty due to multiple incompatibilities. For example, GHC requires GMP 3, but Trusty only provides GMP >= 4. Etc. I tried building GHC 7.4.2. from source on Trusty. But the process won't boot from our currently installed GHC 7.8.3. The oldest GHC binary I can get is GHC 7.6.3, which happens to be still available from the Ubuntu distribution itself (neither the binary tarball nor compiling from source work for GHC 7.6.3 on Trusty either). But booting from GHC 7.6.3 won't work either. How do I get a working GHC 7.4.2 on Trusty? Thanks, Yitz

3 2

GADTs in implementation of Template Haskell
by Richard Eisenberg 21 Oct '14

21 Oct '14

I'm doing a bunch of bug-fixes / improvements to Template Haskell. Two of these are to fix GHC bugs #8100 (add standalone-deriving support) and #9064 (add `default` method type signature support), both of which introduce new constructors for `Dec`. This got me thinking about `Dec` and the fact that different declaration forms are allowable in different contexts. (For example, datatype declarations are allowable only at the top level, and fixity declarations are allowable anywhere except in instance declarations.) How to encode these restrictions? With types, of course! Thus, I redesigned `Dec` to be a GADT. Having done so, I'm not 100% convinced that this is the right thing to do. I would love feedback on my full, concrete proposal available at https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs Is this a change for the better or worse? Feel free either to comment on the wiki page or to this email. Thanks! Richard

2 1

Dynamic only GHC
by Jeremy 20 Oct '14

20 Oct '14

I'm trying to build a minimal GHC 7.8.3 on Debian Wheezy with only dynamic libraries (this is for a system where disc space is scarce). I'm using this build.mk: GhcRTSWays = thr GhcLibWays = dyn HADDOCK_DOCS = NO DYNAMIC_BY_DEFAULT = YES GhcDynamic = YES Tried with and without GhcDynamic (asked on beginners how it's different to DYNAMIC_GHC_PROGRAMS but still waiting for an answer). It gets near the end of the build, then fails with: HC [stage 1] ghc/stage2/build/Main.dyn_o HC [stage 1] ghc/stage2/build/tmp/ghc-stage2 /usr/bin/ld: cannot find -lHSrts_thr-ghc7.8.3 collect2: error: ld returned 1 exit status make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2 If I build with only static libraries, everything seems to work OK.

2 5

GHC 7.8.4: call for tickets, show stoppers, and timelines - oh my!
by Austin Seipp 18 Oct '14

18 Oct '14

Hi *, After some discussion with Simon & Mikolaj today, I'd like to direct you all at this: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4 This status page is the basic overview of what we plan on doing for 7.8.4. There are two basic components to this page: - Show stopping bugs. - Everything else, which is "nice to have". Show stoppers are listed at the top of the page, in the first paragraph. Right now, this includes: - #9439 - LLVM mangling too vigorously. - #8819 - Arithmetic failures for unregistered systems - #8690 - SpecConstr blow-up And that's all. But what's all the other stuff? That's "everything else". Aside from these tickets listed here - and any future amendments to it - all other tickets will only be considered nice-to-have. What does that mean? - It's low risk to include. - It clearly fixes the problem - It doesn't take Austin significant amounts of time to merge. For example, "Tickets marked merge with no milestone" are all nice-to-have. Similarly, all the *closed tickets* on this page may be re-opened and merged again[1], since most didn't make it to 7.8.4. Ditto with the remaining categories. OK, so that's the gist. Now I ask of you the following: - If you have a show-stopping bug with GHC 7.8.3, **you really, _positively_ need to file a bug, and get in contact with me ASAP**. Otherwise you'll be waiting for 7.10 most likely. - Again: if you have a show stopper, contact me. Very soon. - If there are bugs you *think* are showstoppers, but we didn't categorize them properly, let me know. Anything we accept as a show-stopper will delay the release of 7.8.4. Anything else can (and possibly will) be left behind. Luckily, almost all of the show stoppers have patches. Only #8819 does not, but I have asked Sergei to look into it for me if he has time today. Finally, I would please ask that users/developers do not include their own personal pet tickets under "show stoppers" without consulting me first, at least. :) If it's just nice to have, you can still pester me, of course, and I'll try to make it happen. I would like to have 7.8.4 out and done with by mid November, before we freeze the new STABLE branch for 7.10.1. That's not a hard deadline; just a timeframe I'd like to hit. Let me know if you have any questions or comments; thanks! [1] A lot of the closed tickets on this page had an improper milestone set, which is why they show up. You can mostly ignore them, I apologize. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Re: Windows build broken in Linker.c
by John Wiegley 17 Oct '14

17 Oct '14

>>>>> Simon Marlow <marlowsd(a)gmail.com> writes: > I was working on a fix yesterday but ran out of time. Frankly this code is a > nightmare, every time I touch it it breaks on some platform - this time I > validated on 64 bit Windows but not 32. Aargh indeed. Before I start breaking this code up into pieces, do we have tests that solely target the linking sub-components, and how would I run them? Perhaps I can setup a fleet of virtual machines to try it out in every combination where we expect the code to compile. John

2 1