- ghc-devs - Haskell.org

Re: Uppercase OverloadedLabels
by Ryan Scott 08 Apr '20

08 Apr '20

No particular reason. There is an accepted GHC proposal to relax this restriction [1], as well as an accompanying GHC issue [2], but it has not yet been implemented. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-u… [2] https://gitlab.haskell.org/ghc/ghc/issues/11671

1 0

Targeting old Windows versions
by Andreas Klebinger 08 Apr '20

08 Apr '20

Hello devs, GHC is planning to use the Large Address Space mode of allocation for future releases on windows. See https://gitlab.haskell.org/ghc/ghc/issues/12576 This is a significant optimization for the GC and well tested as we use it on Linux already. However it will regress memory useage on versions of windows *older* than Windows 8.1/Sever 2012. Please let us know if you are targeting older versions than that either by responding to the mailing list, commenting on the ticket or contacting me directly if you have privacy concerns. Depending on how many people are affected by this change we might consider measures to reduce the impact. Cheers, Andreas

1 0

Uppercase OverloadedLabels
by Alejandro Serrano Mena 07 Apr '20

07 Apr '20

Dear Haskell-Café / GHC devs, Is there any reason why the `OverloadedHaskell` extension does not work with labels starting with an uppercase letter? Kind regards, Alejandro

1 0

Fusing loops by specializing on functions with SpecConstr?
by Alexis King 06 Apr '20

06 Apr '20

Hi all, I have recently been toying with FRP, and I’ve noticed that traditional formulations generate a lot of tiny loops that GHC does a very poor job optimizing. Here’s a simplified example: newtype SF a b = SF { runSF :: a -> (b, SF a b) } add1_snd :: SF (String, Int) (String, Int) add1_snd = second add1 where add1 = SF $ \a -> let !b = a + 1 in (b, add1) second f = SF $ \(a, b) -> let !(c, f') = runSF f b in ((a, c), second f') Here, `add1_snd` is defined in terms of two recursive bindings, `add1` and `second`. Because they’re both recursive, GHC doesn’t know what to do with them, and the optimized program still has two separate recursive knots. But this is a missed optimization, as `add1_snd` is equivalent to the following definition, which fuses the two loops together and consequently has just one recursive knot: add1_snd_fused :: SF (String, Int) (String, Int) add1_snd_fused = SF $ \(a, b) -> let !c = b + 1 in ((a, c), add1_snd_fused) How could GHC get from `add1_snd` to `add1_snd_fused`? In theory, SpecConstr could do it! Suppose we specialize `second` at the call pattern `second add1`: {-# RULE "second/add1" second add1 = second_add1 #-} second_add1 = SF $ \(a, b) -> let !(c, f') = runSF add1 b in ((a, c), second f') This doesn’t immediately look like an improvement, but we’re actually almost there. If we unroll `add1` once on the RHS of `second_add1`, the simplifier will get us the rest of the way. We’ll end up with let !b1 = b + 1 !(c, f') = (b1, add1) in ((a, c), second f') and after substituting f' to get `second add1`, the RULE will tie the knot for us. This may look like small potatoes in isolation, but real programs can generate hundreds of these tiny, tiny loops, and fusing them together would be a big win. The only problem is SpecConstr doesn’t currently specialize on functions! The original paper, “Call-pattern Specialisation for Haskell Programs,” mentions this as a possibility in Section 6.2, but it points out that actually doing this in practice would be pretty tricky: > Specialising for function arguments is more slippery than for > constructor arguments. In the example above the argument was a > simple variable, but what if it was instead a lambda term? [...] > > The trouble is that lambda abstractions are much more fragile than > constructor applications, in the sense that simple transformations > may make two abstractions look different although they have the > same value. Still, the difference this could make in a program of mine is so large that I am interested in exploring it anyway. I am wondering if anyone has investigated this possibility any further since the paper was published, or if anyone knows of other use cases that would benefit from this capability. Thanks, Alexis

5 16

Re: Building libraries with an in-place GHC
by Ryan Scott 06 Apr '20

06 Apr '20

Hi Simon, As #18018 says, you need to use head.hackage to reproduce it. This page [1] contains a rather short tutorial on how to use it, but Ben is currently drafting a more detailed tutorial on its use here [2]. This is what I use whenever building any Hackage library with GHC HEAD. Ryan S. ----- [1] https://ghc.gitlab.haskell.org/head.hackage/ [2] https://gitlab.haskell.org/ghc/homepage/-/merge_requests/29

1 0

Building libraries with an in-place GHC
by Simon Peyton Jones 06 Apr '20

06 Apr '20

Devs I want to reproduce #18018, but that needs me to build pandoc with my freshly-built HEAD. I tried this (below) but as you can see that didn't work. What should I do? Thanks Simon bash$ cabal install --with-compiler=/home/simonpj/code/HEAD-3/inplace/bin/ghc-stage2 --package-db=/home/simonpj/code/HEAD-3/inplace/lib/package.conf.d pandoc-2.9.2.1 Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: pandoc-2.9.2.1 (user goal) [__1] trying: zlib-0.6.2.1 (dependency of pandoc) [__2] trying: base-4.14.0.0/installed-4.14.0.0 (dependency of zlib) [__3] next goal: haddock-library (dependency of pandoc) [__3] rejecting: haddock-library-1.8.0 (conflict: base==4.14.0.0/installed-4.14.0.0, haddock-library => base>=4.7 && <4.14) [__3] skipping: haddock-library-1.7.0, haddock-library-1.6.0, haddock-library-1.5.0.1, haddock-library-1.4.5, haddock-library-1.4.4, haddock-library-1.4.3, haddock-library-1.4.2, haddock-library-1.4.1, haddock-library-1.2.1, haddock-library-1.2.0, haddock-library-1.1.1, haddock-library-1.1.0, haddock-library-1.0.1, haddock-library-1.0.0, haddock-library-1.6.1 (has the same characteristics that caused the previous version to fail: excludes 'base' version 4.14.0.0) [__3] fail (backjumping, conflict set: base, haddock-library, pandoc) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: pandoc, base, haddock-library, zlib Try running with --minimize-conflict-set to improve the error message. bash$ cabal --version cabal-install version 3.2.0.0 compiled using version 3.2.0.0 of the Cabal library

1 0

Module Renaming: GHC.Core.Op
by Andreas Klebinger 06 Apr '20

06 Apr '20

Hello devs, While I looked at the renaming a bit when proposed I only just realized we seem to be using Op as a short name for optimize. I find this very unintuitive. Can we spare another letter to make this GHC.Core.Opt instead? We use opt pretty much everywhere else in GHC already. Cheers Andreas

5 6

Advice implementing new constraint entailment rules
by Matthew Pickering 02 Apr '20

02 Apr '20

Hello, I am attempting to implement two new constraint entailment rules which dictate how to implement a new constraint form "CodeC" can be used to satisfy constraints. The main idea is that all constraints store the level they they are introduced and required (in the Template Haskell sense of level) and that only constraints of the right level can be used. The "CodeC" constraint form allows the level of constraints to be manipulated. Therefore the two rules In order to implement this I want to add two constraint rewriting rules in the following way: 1. If in a given, `CodeC C @ n` ~> `C @ n+1` 2. If in a wanted `CodeC C @ n` -> `C @ n - 1` Can someone give me some pointers about the specific part of the constraint solver where I should add these rules? I am unsure if this rewriting of wanted constraints already occurs or not. Cheers, Matt

2 4

License for grammar
by Евгений Слободкин 01 Apr '20

01 Apr '20

Hi all! I implemented Haskell grammar for ANTLRv4 based on HaskellReport 2010 and GHC source (Parser.y and Lexer.x files). Link: https://github.com/antlr/grammars-v4/blob/master/haskell/Haskell.g4 Could someone please help me figuring out which license this grammar should be published on?

3 2

Re: intent to enable 2fa requirement for github.com/haskell org
by Carter Schonwald 25 Mar '20

25 Mar '20

Duncan, David, please figure out 2fa tools that work for you and enable them, https://github.com/tadfisher/pass-otp https://github.com/solokeys/solo https://github.com/herrjemand/awesome-webauthn#hardware-authenticators https://1password.com/ https://keepass.info/download.html if you are having trouble figuring out tools you're comfortable using, please share with us those constraints we can help you! im here to help (and i'm delaying enabling another day or two to provide help to some active contributors who are having their own difficulties setitng up this stuff) On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan(a)dcoutts.me.uk> wrote: > On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote: > > hey everyone, because so much important stuff for the community, it > > makes sense to add 2fa required for the org, are there any good > > reasons to either wait to do this, or not do it? Feedback welcome! > > I think I might get cut off. > > Is it not still the case that github's 2fa needs a program running on a > mobile phone, or an SMS-capable mobile phone? Is there any support for > normal tools running on a normal Linux machine? > > (I think last time I tried to use the SMS route, it refused to send SMS > messages to my landline, despite the fact that I can receive them) > > > Duncan > >

2 2