- ghc-devs - Haskell.org

Reading source annotations during type checking
by Alejandro Serrano Mena 20 Dec '16

20 Dec '16

Dear GHC devs, Is there a way to retrieve "source annotations" (as defined by https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_g…) during type checking. In particular, I am interested in reading them in TcExpr and TcCanonical. Regards, Alejandro

3 3

Will directory 1.3.0.0 be shipped with GHC 8.0.2?
by Andrés Sicard-Ramírez 20 Dec '16

20 Dec '16

Dear all, I got directory 1.3.0.0 after installing GHC 8.0.2 RC2 (which hasn't been announced) using: $ git clone http://git.haskell.org/ghc.git $ cd ghc $ git checkout ghc-8.0.2-rc $ git submodule update --init $ perl boot $ ./configure $ make $ make install Will GHC 8.0.2 do a major version bump of directory? Best, -- Andrés La información contenida en este correo electrónico está dirigida únicamente a su destinatario y puede contener información confidencial, material privilegiado o información protegida por derecho de autor. Está prohibida cualquier copia, utilización, indebida retención, modificación, difusión, distribución o reproducción total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elimínelo. La información aquí contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga. The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains.

2 1

haskell.org not sending intermediate certs
by Edward Z. Yang 19 Dec '16

19 Dec '16

See: https://www.sslshopper.com/ssl-checker.html#hostname=www.haskell.org This is causing curl to fail to download it: ezyang@sabre:~/Downloads$ curl https://www.haskell.org/cabal/release/cabal-install-1.24.0.0/cabal-install-… curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. Apologies if this is the wrong list. Thanks, Edward

3 3

Re: Help needed: Restrictions of proc-notation with RebindableSyntax
by Richard Eisenberg 19 Dec '16

19 Dec '16

> On Dec 17, 2016, at 9:19 AM, Ross Paterson <R.Paterson(a)city.ac.uk> wrote: > > On Tue, Nov 29, 2016 at 12:41:53PM +0000, Simon Peyton Jones wrote: >> Type checking and desugaring for arrow syntax has received Absolutely >> No Love for several years. I do not understand how it works very well, >> and I would not be at all surprised if it is broken in corner cases. >> >> It really needs someone to look at it carefully, document it better, and >> perhaps refactor it – esp by using a different data type rather than >> piggy-backing on HsExpr. > > HsCmd was split from HsExpr in 2012. It still re-uses MatchGroup, Stmt, > etc, though. > > The desugaring is made more complicated by doing a lot of analysis that > might be better done in the renamer. And -- unrelated to the original post in this thread -- these complications in desugarer (specifically, the use of fixM) are making my incoming levity-polymorphism update much harder (see https://phabricator.haskell.org/D2852) Even if you don't have time to make the edits yourself, if you could give a 10,000 ft view as to how to remove fixM from the desugarer, I'd be very grateful. I've not looked deeply at this, mostly because it's hard for me to make anything but very local changes to code I don't understand. Thanks! Richard

1 0

Patch for time repository
by Edward Z. Yang 18 Dec '16

18 Dec '16

Hi all, I'd like to push the following patch (see bottom of email) to GHC's time repository, but I do not seem to have permissions. Upstream has already taken the fix but the version we currently have in the repo is quite a bit older than upstream. Can someone do it for me / give me bits? Thanks. Edward commit 44c23839f964592946c889626f8acbd1f4f72e55 Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> Date: Sat Dec 17 20:05:11 2016 -0800 Remove useless internal library version bounds. These bounds never do anything, and in Cabal HEAD cause errors which cause GHC's build system to choke. Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> diff --git a/time.cabal b/time.cabal index 4a6eb02..28f2c21 100644 --- a/time.cabal +++ b/time.cabal @@ -100,7 +100,7 @@ test-suite ShowDefaultTZAbbreviations ghc-options: -Wall -fwarn-tabs build-depends: base, - time == 1.6.0.1 + time main-is: ShowDefaultTZAbbreviations.hs test-suite tests @@ -122,7 +122,7 @@ test-suite tests build-depends: base, deepseq, - time == 1.6.0.1, + time, QuickCheck >= 2.5.1, test-framework >= 0.8, test-framework-quickcheck2 >= 0.3,

1 1

FYI: base version bump landing soon
by Ben Gamari 15 Dec '16

15 Dec '16

Hello fellow Haskellers, Sometime soon (likely today) I'll be landing a commit to `master` which will bump the version of the `base` library to 4.10.0.0 This will involve bumping a number of submodules as well. This will mean that testing against Hackage will typically require that you pass `--allow-newer=base` to cabal. Cheers, - Ben

1 0

Compile GHC with -prof to get a stack trace on panic
by Simon Marlow 15 Dec '16

15 Dec '16

I think this has been mentioned before but it's probably not widely known: if you compile GHC profiled (that is, enable GhcProfiled=YES in your mk/ build.mk), then every panic comes with a stack trace. Here's one I just saw: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161206 for x86_64-unknown-linux): Ix{Int}.index: Index (65536) out of range ((0,28)) CallStack (from -prof): HscTypes.bin_fixities (compiler/main/HscTypes.hs:1050:51-56) HscMain.checkOldIface (compiler/main/HscMain.hs:(586,20)-(587,60)) HscMain.hscIncrementalFrontend (compiler/main/HscMain.hs:(556,1)-(618,81)) HscMain.hscIncrementalCompile (compiler/main/HscMain.hs:(644,1)-(699,32)) GHC.withCleanupSession (compiler/main/GHC.hs:(464,1)-(473,27)) GHC.runGhc (compiler/main/GHC.hs:(439,1)-(444,26)) GHC.defaultErrorHandler (compiler/main/GHC.hs:(379,1)-(411,7)) To get more detail in the stack trace you need to add GhcStage2HcOpts += -fprof-auto-top Or -fprof-auto, depending on how much detail you want. Cheers Simon

1 0

Explicit inequality evidence
by David Feuer 15 Dec '16

15 Dec '16

According to Ben Gamari's wiki page[1], the new Typeable is expected to offer eqTypeRep :: forall k (a :: k) (b :: k). TypeRep a -> TypeRep b -> Maybe (a :~: b) Ideally, we'd prefer to get either evidence of equality or evidence of inequality. The traditional approach is to use Dec (a :~: b), where data Dec a = Yes a | No (a -> Void). But a :~: b -> Void isn't strong enough for all purposes. In particular, if we want to use inequality to drive type family reduction, we could be in trouble. I'm wondering if we could expose inequality much as we expose equality. Under an a # b constraint, GHC would recognize a and b as unequal. Some rules: Base rules 1. f x # a -> b 2. If C is a constructor, then C # f x and C # a -> b 3. If C and D are distinct constructors, then C # D Propagation rules 1. x # y <=> (x -> z) # (y -> z) <=> (z -> x) # (z -> y) 2. x # y <=> (x z) # (y z) <=> (z x) # (z y) 3. If x # y then y # x Irreflexivity 1. x # x is unsatisfiable (this rule would be used for checking patterns). With this hypothetical machinery in place, we could get something like data a :#: b where Unequal :: a # b => Unequal (a :#: b) eqTypeRep' :: forall k (a :: k) (b :: k). TypeRep a -> TypeRep b -> Either (a :#: b) (a :~: b) Pattern matching on an Unequal constructor would reveal the inequality, allowing closed type families relying on it to reduce. Evidence structure: Whereas (:~:) has just one value, Refl, it would be possible to imagine richer evidence of inequality. If two types are unequal, then they must be unequal in some particular fashion. I conjecture that we don't actually gain much value by using rich evidence here. If the types are Typeable, then we can explore them ourselves, using eqTypeRep' recursively to locate one or more differences. If they're not, I don't think we can track the source(s) of inequality in a coherent fashion. The information we got would only be suitable for use in an error message. So one option would be to bundle up some strings describing the known mismatch, and warn the user very sternly that they shouldn't try to do anything too terribly fancy with them. [1] https://ghc.haskell.org/trac/ghc/wiki/Typeable/BenGamari

4 7

Join points!
by Simon Peyton Jones 15 Dec '16

15 Dec '16

Everyone: please take a look. Luke Very good. · I think it’s fine to work from your repo; no need to use the main repo. · One big patch is fine. The exception is late lambda-lifting which would best be done separately. · Can you identify any bits that you are less happy with? · Before long, can you put up nofib figures? Make a Trac ticket for this too. On Phab, you can have dialogue about “what does this line of code mean”. On Trac you can have longer-term strategic concerns. There isn’t a clear boundary. But Trac persists and Phab really doesn’t. We should talk about your question about floating. Simon From: Luke Maurer [mailto:maurerl@cs.uoregon.edu] Sent: 15 December 2016 10:52 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Phab diff up Okay, after some further cleanups, I've put up a Phabricator diff: https://phabricator.haskell.org/D2853 (Has some lint failures, but I figure better to put it up sooner … will fix after I get some sleep) Was going to push to a branch in the official GHC repo, too, but I don't think I have push access? Anyway, should I try and split it up into pieces? Hard to see how that would work, given how many interconnected pieces there are. I suppose if you apply the changes to Core Lint last, it might work … Also, the patch includes the stuff from the late lambda-lifting branch, which is perhaps more than we want to push at once! Certainly that much is splittable, if desired. I'm also just not as happy with that code. - Luke

1 0

Fwd: [Ann] Haskell Ecosystem Proposals
by Alan & Kim Zimmerman 15 Dec '16

15 Dec '16

I am forwarding this mail to ghc-devs and cabal-devs in case anyone missed the original which went to haskell-cafe only. Alan ---------- Forwarded message ---------- From: Alan & Kim Zimmerman <alan.zimm(a)gmail.com> Date: Sun, Dec 11, 2016 at 9:39 PM Subject: [Ann] Haskell Ecosystem Proposals To: haskell <haskell-cafe(a)haskell.org> Earlier this year Simon Peyton Jones wrote about respect [1], and said "It's worth separating two things 1. Publicly debating an issue where judgements differ 2. Using offensive or adversarial language in that debate" There is now a repository[2] for us as a community to have the first kind of discussion about issues that affect the community as a whole. The intention is that this becomes a neutral place where discussion can take place about coordinating the various services offered to the haskell community. This is partly to expose the thinking and constraints on a particular approach, so proponents of other approaches can have a better understanding of how things can evolve. The idea is that through an honest understanding of the various parts we can achieve consensus on how to improve things. If this all sounds a bit handwavy, the first concrete example of this approach is a pull request [3] discussing the management of implicit or speculative version bounds between cabal-install/hackage and stack/stackage. This has reached a point where there is a clearer understanding of the actual problem, and a viable solution must be agreed. The structure of the repository is shamelessly copied from the one for GHC proposals, so the actual process description is way off. It should probably just state that we discuss until consensus is reached if possible, but that we are always open for further discussion. It is up to all of us to make this work. Regards Alan [1] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html [2] https://github.com/haskell/ecosystem-proposals [3] https://github.com/haskell/ecosystem-proposals/pull/1

1 0