RE: A GHC Library

I'm happy to give blanket permission for my papers for myself. But they are almost all ACM copyright, so someone would need to check on the ACM rules. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Eric | Seidel | Sent: 08 December 2015

RE: D808 progress report

Kind equalities are the Big New Thing in 8.0. Let's just get it in and deal with the fallout. After all, there is no reason for performance to be worse. For programs that 7.10 accepts, 8.0 should yield essentially the same coercions. They might need a bit of optimisation to squeeze them down

Re: [GHC] #11177: panic! tc_hs_type: record

I am travelling until Thursday, will only be able to look on Friday. Alan On 08 Dec 2015 2:44 PM, "GHC" wrote: > #11177: panic! tc_hs_type: record > -+- > Reporter: apanagio |

RE: Plugins: Accessing unexported bindings

I think it’s probably the desugarer, and the plugin can’t do anything before desugaring! By all means open a ticket. I can advise if anyone wants to take it up. Simon From: Levent Erkok [mailto:erk...@gmail.com] Sent: 08 December 2015 03:32 To: Simon Peyton Jones Cc:

RTS linker refactoring

Hi devs, I have made a patch to refactor the RTS linker, especially to drastically reduce its memory usage: https://phabricator.haskell.org/D1470 We need to test it on differrent OS/architectures before it can be merged. Here is the current state: - Linux/x86-64: OK (Harbormaster and I) -

Re: RTS linker refactoring

Ben Gamari writes: > Sylvain Henry writes: > >> Hi devs, >> >> I have made a patch to refactor the RTS linker, especially to drastically >> reduce its memory usage: https://phabricator.haskell.org/D1470 >> >> We need to test it on differrent

RE: -XStrict: Why some binders are not made strict?

Adam, Johan, Looking at the user manual http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#strict-haskell, and indeed the wiki page https://ghc.haskell.org/trac/ghc/wiki/StrictPragma it's not really clear whether the sub-components of a pattern are strict. That is, is the

User manual sub-sections

Ben, Austin, Could we see the sub-sub-sections of the user manual in the table of contents http://downloads.haskell.org/~ghc/master/users-guide/ The section titles are often very helpful. C.f. the old version https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html Simon

Re: User manual sub-sections

Simon Peyton Jones writes: > Ben, Austin, > Could we see the sub-sub-sections of the user manual in the table of contents > http://downloads.haskell.org/~ghc/master/users-guide/ > The section titles are often very helpful. C.f. the old version >

Re: RTS linker refactoring

Sylvain Henry writes: > Hi devs, > > I have made a patch to refactor the RTS linker, especially to drastically > reduce its memory usage: https://phabricator.haskell.org/D1470 > > We need to test it on differrent OS/architectures before it can be merged. > Here is the current

Re: User manual sub-sections

Simon Peyton Jones writes: > Ben, Austin, > Could we see the sub-sub-sections of the user manual in the table of contents > http://downloads.haskell.org/~ghc/master/users-guide/ > The section titles are often very helpful. C.f. the old version >

Re: User manual sub-sections

On 12/8/15 7:41 AM, Ben Gamari wrote: > Simon Peyton Jones writes: >> Could we see the sub-sub-sections of the user manual in the table of contents >> http://downloads.haskell.org/~ghc/master/users-guide/ >> The section titles are often very helpful. C.f. the old version

RE: Questions concerning the LLVM backend - i.e. 'proc point splitting'

David | Could you explain the need of further info-tables for 'inner' | proc-points (those, which are not the entry-block of a function) to | me, please? The main purpose of inner info tables is this. Given (case e of blah) we push a return address (for 'blah') on the stack and evaluate

RE: Allow ambiguous types (with warning) by default

Sure, I'll open the ticket. It may well turn out that there's a less invasive way to accomplish my ultimate goal (more useful error messages for ambiguous types) without allowing the cascade you're worried about. In foo :: Num a => F a -> G a Something more like the following would be much

RE: User manual sub-sections

I like it better. Better still to be able to collapse/expand. But it should be possible to collapse-all and expand-all, so you can then search in the web page. S | -Original Message- | From: Ben Gamari [mailto:b...@smart-cactus.org] | Sent: 08 December 2015 15:42 | To: Simon Peyton

Submodules on a branch

· I’m on a branch wip/T11067. · I do a ‘git merge origin/master’, resolve source code conflicts and commit · Then ‘git submodule update’ · I have not touched libraries/unix · Yet when I say “git submodule” in a different HEAD tree, I get a different

Re: Does the Strict extension make monadic bindings strict?

While there's a fundamental difference between (>>=) and let-bindings, it might be worth adding to the docs that -XStrict only makes let bindings strict. On 12/08/2015 06:22 PM, Rob Stewart wrote: > Are the following two programs equivalent with respect to the strictness > of `readFile`? > >

Does the Strict extension make monadic bindings strict?

Are the following two programs equivalent with respect to the strictness of `readFile`? --8<---cut here---start->8--- {-# LANGUAGE BangPatterns #-} module Main where main = do !contents <- readFile "foo.txt" print contents --8<---cut

Re: Submodules on a branch

Simon Peyton Jones writes: > · I’m on a branch wip/T11067. > Hi Simon! > · I do a ‘git merge origin/master’, resolve source code conflicts and > commit > > · Then ‘git submodule update’ > > · I have not touched libraries/unix > > · Yet when I say “git submodule”

Re: Does the Strict extension make monadic bindings strict?

I think this is a problem/bug in the implementation. In the "function definitions" section of the wiki page it says the argument will have a bang pattern. But then this code: do x <- ... return (x + 1) which is just a syntactic sugar for `... >>= \x -> return (x + 1)` doesn't have the

Re: Plugins: Accessing unexported bindings

http://ghc.haskell.org/trac/ghc/ticket/11179#ticket Thanks! -Levent. On Tue, Dec 8, 2015 at 4:33 AM, Simon Peyton Jones wrote: > I think it’s probably the desugarer, and the plugin can’t do anything > before desugaring! > > > > By all means open a ticket. I can advise

Another question about -XStrict: Why not implement it as a Core pass?

So this is another question comes to mind. It seems to me like it would be a lot easier to implement, we could even implement it as a plugin, without changing anything in GHC. (I mean -XStrict, not -XStrictData) I'm wondering why it's currently implemented on Haskell syntax. Any ideas? Is it

Non-exported class constraints in errors

The latest implementation of Data.Constraint.Forall uses type family Forall (p :: k -> Constraint) :: Constraint where Forall p = Forall_ p class p (Skolem p) => Forall_ (p :: k -> Constraint) instance p (Skolem p) => Forall_ (p :: k -> Constraint) The trouble is that errors relating to Forall

runghc fails on Windows with GHC HEAD

For some reason, I can't get runghc to work with GHC HEAD. Compiling with ghc-stage2 and running ghc-stage2 --interactive both work okay, it's just runghc that doesn't want to cooperate for some reason: $ .\ghc\inplace\bin\runghc.exe Z.hs runghc.exe:

Re: runghc fails on Windows with GHC HEAD

Actually, this might not be Windows-related at all. It turns out that runghc was failing because there wasn't a ghc.exe located in inplace/bin (just ghc-stage1.exe and ghc-stage2.exe). Adding a ghc.exe symlink to ghc-stage2.exe made runghc.exe work correctly. Is this a bug, or the intended

Re: runghc fails on Windows with GHC HEAD

Definitely a bug, the in-place runghc should properly use the in-place compiler. Not sure when it regressed though, but it wouldn't be surprising if this has been happening for a while. On Tue, Dec 8, 2015 at 5:19 PM, Ryan Scott wrote: > Actually, this might not be

Re: D808 progress report

On Dec 8, 2015, at 7:22 AM, Simon Peyton Jones wrote: > Kind equalities are the Big New Thing in 8.0. Let's just get it in and deal > with the fallout. > > After all, there is no reason for performance to be worse. For programs that > 7.10 accepts, 8.0 should yield

A comment on Introspective-Haskell

I just came across https://ghc.haskell.org/trac/ghc/ticket/11081, and the corresponding wiki-page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective I think this is a terrific idea. In the past, I've tried both TH and haskell-src-exts to do relatively simple things, but ended-up

Re: D808 progress report

I've just updated the nokinds-dev branch with the latest. It should compile with bootstrapping from 7.8. Haddock should also compile, but only after doing this from utils/haddock: > git remote add goldfire git://github.com/goldfirere/haddock.git > git fetch goldfire For some reason, I