- ghc-devs - Haskell.org

Re: -fno-warn lines in the lexer can be removed with Alex 3.1.5
by Ryan Scott 11 Sep '16

11 Sep '16

That sounds like a reasonable suggestion to me. I'm not aware of any support window for we have for alex/happy, but since alex-3.1.5 is already about one year old, I can't imagine requiring it as a minimum would cause any problems. Ryan S.

1 0

Feature request bounty
by David Feuer 08 Sep '16

08 Sep '16

I'd like to place a small bounty on https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS . If someone implements this request by GHC 8.2, I will buy them 24 bottles of high-end root beer (e.g., Maine Root) or something of similar value agreeable to both parties. (*) Thanks, David Feuer (*) Recipient responsible for customs/duty/taxes/shipping fees beyond US$10.

4 6

Thoughts on CallStack and withFrozenCallStack
by Edward Z. Yang 08 Sep '16

08 Sep '16

I've been adding CallStack to Cabal's source code, and I noticed a common pattern that doesn't seem to be supported by the GHC.Stack API. Imagine I'm writing a general purpose logging function: debug :: Verbosity -> String -> IO () I'd like this function to print out the SrcLoc of the person who called; as an additional requirement, I only want to print the top-most stack frame by default (someone can ask for the full stack if they really want to). If I look at callStack, it is going to contain a stack frame for debug itself. That's not so great; the obvious way to fix this is to pop off the irrelevant frame manually. But now suppose that I have a pprDebug which itself calls debug. I don't want pprDebug to show up in the stack frame! Declaratively, I want to say, "Please don't add me to the call stack", at the function *definition*, not the call-site (which is what withFrozenCallStack) gives me. Does this seem like a reasonable request? I have several other ways to do this: - You could just use withFrozenCallStack at the definition site. Then when pprDebug calls debug, debug will get the call stack that pprDebug had; thus, there will always only be one irrelevant frame to pop off. - One problem with using withFrozenCallStack is that you *do* lose useful trace information, which you kind of might actually want if you are being verbose. So it almost seems like, the frozen API should still *push* frames, but just not make them visible by default. - Something that does NOT work is having functions edit the call stack to remove themselves. There's no way to tell if the stack is frozen or not, and thus no way to tell if you are actually on the stack (and need to remove it.) Thanks, Edward

2 2

Restartable sequences
by Ben Gamari 07 Sep '16

07 Sep '16

While I'll admit that I'm not terribly familiar with our STM implementation, it came to mind while I was reading this article [1] on the restartable sequences mechanism that might someday land in the Linux kernel. I thought you both might be interested. Cheers, - Ben [1] http://lwn.net/Articles/697979/

1 0

OSX Test Failures
by Matthew Pickering 06 Sep '16

06 Sep '16

Occasionally a do a full validate on OSX, there are usually some tests which fail but not on other systems. I usually don't report these failures as there are always some and they are usually do to do with parts of the compiler I don't know anything about. However, on https://phabricator.haskell.org/D2485 Richard (Fung) and Ben were discussing these failures which I have also seen so it seems I would have wasted less time if I had reported these somewhere. What is the expectation for OSX? Should the test suite be entirely clean? Should I create issues when some of the tests get broken? Matt

2 2

Tooling-friendly ModSummary
by Alan & Kim Zimmerman 05 Sep '16

05 Sep '16

At the moment the standard way to use the GHC API is something like _ <- load LoadAllTargets modSum <- getModSummary mn p <- parseModule modSum And likewise if renamed or typechecked ASTs are needed. But the `load` step already does all those phases. So, would there be any objection to modifying the ModSummary to possibly retain those artifacts, configurable via a DynFlag? I would expect the flag would default to retaining none, but could then either provide for returning all artifacts, or just for the targets explicitly listed in the `setTargets` call (i.e. not the full `depanal` result). Regards Alan

2 2

cabal
by Simon Peyton Jones 05 Sep '16

05 Sep '16

I’m trying to follow the instructions for https://ghc.haskell.org/trac/ghc/ticket/12562 But I get cabal new-build llvm-general --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc-stage2 cabal: unrecognised command: new-build (try --help) simonpj@cam-05-unx:~/tmp/llvm-general$ Maybe my Cabal is too old. I tried bash$ cabal install Cabal Resolving dependencies... Downloading Cabal-1.24.0.0... Configuring Cabal-1.24.0.0... Building Cabal-1.24.0.0... Installed Cabal-1.24.0.0 That worked. But I get the same message. Alas bash$ cabal --version cabal-install version 1.23.0.0 compiled using version 1.23.1.0 of the Cabal library bash$ which cabal /home/simonpj/.cabal/bin/cabal Maybe I need 1.24. Which claims to be installed. But WHERE is it installed? Thanks Simon

3 3

Call for Nominations: GHC Steering Committee
by Ben Gamari 05 Sep '16

05 Sep '16

Hello everyone, As you likely know, over the last few months we have been discussing options for reforming the process for proposing language and compiler changes to GHC. After much discussion, we have a process [1] which, while not perfect, is acceptable to a majority of our contributor base and will be an improvement over the status quo. While we invite suggestions for future improvements, we are at a point where we can move ahead with implementation. Consequently, we are seeking nominations for the initial GHC steering committee. This body is responsible for overseeing the progression of proposals through the process, working with authors on refining their ideas, and evaluating proposals for acceptance. The committee will consist of five to eight members of diverse backgrounds. We would like to offer the following as a criteria for membership. Note that a candidate is not expected to satisfy all or even most of these criteria, but a good candidate should satisfy at least one: * A history of contributions to the design of new language features * Experience developing Haskell libraries and applications * A demonstrated track record of contributing code to GHC * A pedagogical background, with experience in either teaching or authoring educational materials * Experience in compiler development * Knowledge of functional programming language theory I'd like to emphasize that committee membership is as much a duty as it is a privilege. Membership is not intended to be a platform to be used by members to drive their own ideas; rather it is a way of serving the Haskell community by helping other community members refine and advance their proposals. This, of course, requires an investment of time and effort, which you should be willing and able to consistently put forth. If you'd like to be considered for committee membership then please write a statement describing why you feel you are well-qualified to serve, in terms of the criteria above and any others that you would like to offer. Please send your statements to ben(a)well-typed.com by September 30th. The initial committee selection will be made by the Simons soon thereafter. Thanks to everyone for their feedback and cooperation so far! Cheers, - Ben [1] http://github.com/ghc-proposals/ghc-proposals

1 0

RE: Increasing version number of hsc2hs etc.
by Richard Cook 04 Sep '16

04 Sep '16

Perfect! Thanks for taking care of this. -RichardFrom: Ben Gamari Sent: ‎9/‎4/‎2016 6:32 AM To: rcook(a)rcook.org; ghc-devs(a)haskell.org Subject: Re: Increasing version number of hsc2hs etc. Richard Cook <rcook(a)rcook.org> writes: > Hi, > > I recently fixed a bug in hsc2hs which was merged into ghc-8.0. What's the > process around bumping the version number of hsc2hs and publishing a new > version of this package to Hackage? > Richard, for the record Herbert said he would prefer to wait until we are closer to the 8.0.2 release until we push the new release. I've opened GHC Trac #12568 to ensure that we don't lose track of this. Cheers, - Ben

1 0

Increasing version number of hsc2hs etc.
by Richard Cook 04 Sep '16

04 Sep '16

Hi, I recently fixed a bug in hsc2hs which was merged into ghc-8.0. What's the process around bumping the version number of hsc2hs and publishing a new version of this package to Hackage? -Richard

2 2