Re: Should coercion binders (arguments or binders in patterns) be TyVars?

And just to close the loop: the more general coercions that Sebastian has talked about would have computational content, but these are well beyond what GHC supports at the moment (and there are no plans to move in that direction). Richard > On Oct 6, 2019, at 10:38 PM, Simon Peyton Jones via

Re: How does the ambiguity check work

Hi Jan, The ambiguity check has a simple description. To test if a type `ty` is ambiguous, do this: ``` x :: ty x = x ``` Iff that type-checks, the type is unambiguous. That's it! The check does not manufacture a binding `x`, but the implementation runs through the type-checking process for

fragile tests

Hi devs, I believe threadstatus-9333 is more fragile than it's listed as. See https://gitlab.haskell.org/rae/ghc/-/jobs/163182 , where I haven't been anywhere near this area of the code... Also, on a separate test, I found that compact_gc got

Re: Solving stuck type families with a TC plugin

Hi Sandy, I think the problem is that you're generating *Wanted* constraints. A Wanted is something that has not yet been proven, but which you would like to prove. If you have a metavariable a0, then created a Wanted `a0 ~ Bool` will work: you want to prove that, so GHC just unifies a0 :=

Re: Typing rules for Haskell

2019 Per, 02:32 tarihinde şunu > yazdı: >> >> Richard Eisenberg writes: >> >>> Hi devs, >>> >>> Simon and I were wondering about a tight specification for the recent >>> action in proposal #253 >>> (https://github.com/ghc-proposals/gh

Typing rules for Haskell

Hi devs, Simon and I were wondering about a tight specification for the recent action in proposal #253 (https://github.com/ghc-proposals/ghc-proposals/pull/253 ). We needed to see the typing rules. So I made a repo

Re: a better workflow?

> On Jul 23, 2019, at 10:48 PM, Daniel Gröber wrote: > > I don't think you ever mentioned -- are you already using `git > worktree` to get multiple source checkouts or are you working off a > single build tree? I find using it essential to reducing context > switching overhead. This is a good

Re: HIE files?

> On Jul 24, 2019, at 2:38 AM, Zubin Duggal wrote: > > I can clarify any remaining questions you might have. If you are satisfied > with this write up, I can proceed to add it as a Note to HieAst. This has been very helpful -- thanks! There are a few questions that I have, but this email

Re: Tracking issues for GHC proposals?

Yes, please! > On Jul 24, 2019, at 8:40 AM, Ömer Sinan Ağacan wrote: > > Hi all, > > It's currently quite hard to see progress of proposals. For example, I'm > looking > at the "small primitives" proposal [1]. After some digging I can see that it's > mostly (if not completely) implemented [2,

Re: a better workflow?

interactions with it would have to be. Thanks for writing this up. It convinces me to give up on AWS and either find another solution or live with what I have now. Richard > On Jul 23, 2019, at 9:06 PM, Ben Gamari wrote: > > Richard Eisenberg mailto:r...@richarde.dev>> writes

a better workflow?

Hi devs, Having gotten back to spending more time on GHC, I've found myself frequently hitting capacity limits on my machine. At one point, I could use a server at work that was a workhorse, but that's not possible any more (for boring reasons). It was great, and I miss it. So I started

HIE files?

Hi devs, I recently learned about the code for HIE files. This is quite a substantial new development in GHC, judging from the amount of code. I understand broadly why it's here, but I'd like to learn more specifics. For example, if I'm adding a new bit of syntax, how should I update HIE

Re: How do Coercions work

f your > papers following the proofs in there, but I have to read a lot more to be > able to do this on my own. > Thanks again for the help, I think I can dig deeper now :) > Jan > Am 22.07.19 um 21:15 schrieb Richard Eisenberg: >> Hi Jan, >> >>&

Re: How do Coercions work

Hi Jan, > On Jul 22, 2019, at 2:49 PM, Jan van Brügge wrote: > > This also hints that my code there is > utter garbage, as I already suspected. Sorry, but I'm afraid it is. At least about the coercions. > > So I guess my actual question is: What does the coercion returned by >

gitlab subject lines

Hi Ben, Since the recent GitLab upgrade, all GitLab emails have "GHC | Glasgow Haskell Compiler | " prefixed to their subject lines. This reduces the bandwidth of information in my mail reader. Is there a way of going back to just "GHC |"? Thanks! :) Richard

Re: gitlab sometimes slow

0/month" is rather harder than "$100". >> >> On Wed, Jul 17, 2019 at 11:20 AM Richard Eisenberg wrote: >>> >>> Hi all, >>> >>> GitLab is sometimes a bit slow. I understand we host this ourselves, and >>> faster is

gitlab sometimes slow

Hi all, GitLab is sometimes a bit slow. I understand we host this ourselves, and faster is more expensive. My question: how much more expensive? That is, if we throw $100 at the problem, will gitlab be speedy? Will it take $1,000? $10,000? If it's the first one, then let's just blast ahead. If

Re: Workflow question (changing codegen)

Just to pass on something that looks cool (I haven't tried it myself yet): git worktree. It seems git can hang several different checkouts of a repo in different directories. This seems far superior to my current habit of having many clones of ghc, sometimes going through machinations to get

Re: Why is NoExt inhabited?

ity for sums and 1 (that is, Unit) is the identity for products. Sorry if this wasn't clear! Richard > > Forgot to cc list. Pardon the double send :) > > On Mon, Jun 24, 2019 at 11:22 PM Richard Eisenberg <mailto:r...@richarde.dev>> wrote: > I forget if I'm the contributor

Re: Why is NoExt inhabited?

I forget if I'm the contributor Ben mentions below, but regardless: NoExt is used in two separate ways within GHC. It's used both as the extension of a sum (new constructor) and the extension of a product (new field in a constructor). But the identity for sum is different than the identity for

Re: reviewing on GitLab

Thanks, Ben, for this summary. I am happy to wait for a resolution -- as long as there is some hope that waiting will not be in vain. This email indeed gives me this hope. And, for the record, I agree that the merge-train support should be significantly higher priority. The whole merge

Re: reviewing on GitLab

t; > Simon > > | -Original Message- > | From: ghc-devs On Behalf Of Richard > | Eisenberg > | Sent: 06 June 2019 20:34 > | To: Simon Peyton Jones via ghc-devs > | Subject: reviewing on GitLab > | > | Hi all, > | > | I've just reviewed !364, and it was

reviewing on GitLab

Hi all, I've just reviewed !364, and it was a painful experience. Perhaps documenting why will help spur more UI innovations. - My review was in response to several of the author's in-line comments, which themselves were in response to previous in-line comments. This has to be a common

Re: Old build system broken

also fix it. Richard > On May 8, 2019, at 3:51 PM, Richard Eisenberg wrote: > > Me too. I'm on a Mac. Deepest apologies (because I know this makes me > useless), but I don't have the error message any more. It mentioned "Tables > next to code" and the settings file, s

Re: Old build system broken

Me too. I'm on a Mac. Deepest apologies (because I know this makes me useless), but I don't have the error message any more. It mentioned "Tables next to code" and the settings file, so I'm confident that it's related. Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem

Re: MR titles

Might I also suggest that we put a very brief summary of the area of GHC that the MR fixes in the title? With the way that GitLab puts numbers at the end of subject lines, it's harder to recognize tickets by number now. By including a few keywords in the MR title, I can find ones of interest

Re: Is cleaning up old issues worthwhile?

I just want to second comments others have said about the value of this kind of activity. It is most certainly *not* annoying! If you're right and there is a migration issue, then it is indeed reasonable to stop and get feedback, but I'm (for one) comfortable having you close tickets that you

Re: ZuriHac 2019 - GHC Track

I'm also happy to lead a session on GHC. I could perhaps give a high-level overview (no slides, just whiteboard & projected code) on the GHC compilation pipeline. I don't expect it would be terribly hands-on, though I would hope to get lots of questions from the audience. This might most easily

Re: Defining a wired-in type of a different kind

Hi Jan, mkAlgTyCon is good for making an algebraic datatype -- like Maybe or Bool or Either. It's not what you want for RNil, which is really a data constructor. Instead, rowKindCon should be the algebraic datatype, and RNil should be one of its constructors. Then you get the RNil TyCon via

Re: Debug printing inside the typechecker knot

code in the > typechecker knot, and I'd like to codify this solution somewhere where > I can look it up in the future if (when) I eventually forget it. I will point out that this knot is *much* *much* smaller than it once was. But it's never a bad idea to document more. Richard > > Ryan S. &

Re: Debug printing inside the typechecker knot

> On Apr 4, 2019, at 2:55 PM, Ryan Scott wrote: > > Good to know, thanks. I assume that TcMType.zonkTcTypes is to > TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to > TcHsType.zonkTyBndrs? No. You'll see that zonkTcTyVars returns a [TcType], while zonkTyBndrs returns a [TyVar] --

Re: Debug printing inside the typechecker knot

Though a ZonkEnv does some important work when zonking *terms*, it's just an optimization when zonking *types*. You want TcMType.zonkTcType. I hope this helps! Richard > On Apr 4, 2019, at 10:38 AM, Ryan Scott wrote: > > I've recently found myself wanting to add some pprTrace statements in >

Re: Proposal: Don't read environment files by default

> On Mar 28, 2019, at 3:09 PM, Herbert Valerio Riedel > wrote: > > That being said, I'd be more interested to know the actual problems > people are having I've run into two problems. I don't expect others to run into these particular problems, as my workflows are likely different than

Re: Proposal: Don't read environment files by default

> On Mar 28, 2019, at 10:31 AM, Herbert Valerio Riedel > wrote: > > I for one would hate to remove what I consider a useful feature I don't see anyone is asking for a feature removal here. This thread seems to be more about how to set a default. I personally find it surprising for a tool

Re: Proposal: Don't read environment files by default

I have spent quite a bit of time debugging this issue, being utterly surprised about the existence of these files. Furthermore, until today, I had been unable to find a way to turn the feature off. I now understand (https://gitlab.haskell.org/ghc/ghc/issues/13753) that there is an undocumented

Re: [ambiguous occurrence bug?]

This looks like a bug to me. Post at https://gitlab.haskell.org/ghc/ghc/issues/ Thanks! Richard > On Mar 17, 2019, at 1:50 PM, Shayne Fletcher via ghc-devs > wrote: > > Sorry in advance if I should be posting questions of this kind elsewhere >

searching for tickets

Hi devs, Previously, I could effectively use Google as a way to search for contents in tickets, with a query like > site:ghc.haskell.org/blah/blah/tickets > type families (I can't remember the exact URL, and Trac has been taken down so I can't figure

Re: Trac to GitLab migration underway

> On Mar 11, 2019, at 8:13 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > For instance, consider the case of > #16347 [1]. You will note that below the "Related issues" section there > is a list of related merge requests (strangely formatted completely

Re: Trac to GitLab migration underway

the > passive-aggressive form of the initial post. Given that it is email that we > are worrying about, not the browser tabs, maybe it is better to start over > with a new issue referencing that one in passing. > > -- > Best, Artem > > On Mon, 11 Mar 2019 at 11:56 Richard

Re: Trac to GitLab migration underway

out having !123 / #12345 in the front of > mail subjects — I think, this is small but quite important detail to ease > navigating the flow of notifications. > > -- > Best regards, > Artem > > On Mon, Mar 11, 2019, 9:13 AM Richard Eisenberg <mailto:r...@cs.brynmawr.edu>>

Re: Trac to GitLab migration underway

Thanks to all who have made this happen. Looking forward to having everything in one place! Do we have any ability to edit the formatting of subject lines of ticket emails? It would be great if we could get the (!234) or (#12345) up front, as this is the effective summary of what's to follow.

Re: Why can't we re-install the template-haskell package?

I have to admit I don't have a strong grasp on what "reinstallable" implies. Does a package get the same hash after reinstalling? What could make a package not reinstallable? Why aren't packages reinstallable today? Why isn't ghc-prim reinstallable? My concern stems from the fact that ghc is

Re: Testing GHC against Hackage via CI

How will this affect workflow of developers submitting patches? For example, suppose I write a user-facing change that breaks some of these packages. Am I expected to patch up the breakage? How? Will the CI infrastructure detect this before merging or after? To be clear, I don't have specific

gitlab migration

Hi all, As I'm wrapping up some ICFP papers, I realize that I sometimes link to Trac tickets in published papers. It would be a shame for all these links to suddenly go dead, and I'm sure that my papers aren't the only places external sites link to Trac. Is it expected that, after the full

Re: Gitlab bug?

scroll through the page, expanding every file I see, I still can't find these unresolved discussions. :( Richard > On Feb 26, 2019, at 7:59 AM, Richard Eisenberg wrote: > > I can reproduce: > > > > Is there a good place to report this? > > Richard > >> On Fe

Re: scopedSort and kind variable left-biasing

Yes -- sweep it away! > On Feb 14, 2019, at 5:30 PM, Simon Peyton Jones via ghc-devs > wrote: > > What do you (or anyone else) think about sweeping all that stuff away? See > my comments on > https://gitlab.haskell.org/ghc/ghc/merge_requests/361 >

Re: scopedSort and kind variable left-biasing

> On Feb 14, 2019, at 2:32 PM, Ryan Scott wrote: > > I can see the appeal behind dropping this exception, both from a > specification and an implementation point of view. It'll require a massive > breaking change, alas, but it just might be worth it. The "breaking change" is just for

Re: scopedSort and kind variable left-biasing

> On Feb 14, 2019, at 10:34 AM, Ryan Scott wrote: > > the answer [j,a,k,b]! Strictly speaking, this answer meets the specification > of ScopedSort, I wish to point out that the specification of ScopedSort is very tight: it says exactly what we should get, given an input. This is important,

Re: Marge has been stabilised

> On Feb 12, 2019, at 10:51 AM, Matthew Pickering > wrote: > > This can be quickly toggled on/off by typing the /wip quick command in > a comment. This is an interesting aside. I understand this to mean: If I make a comment (the same place that I would write a comment for humans) that

Re: TTG: Handling Source Locations

at this is just a convention -- no one checks it. >> It would be easy to forget. > > I am not sure if I understand: shouldn't the totality checker warn if > there is no pattern for the wrapper constructor (hence enforce the > convention)? > > > On Tue, 12 Feb 2019 at 15:19, Richar

Re: TTG: Handling Source Locations

> On Feb 12, 2019, at 5:19 AM, Shayan Najd wrote: > > About the new code, the convention is straightforward: anytime you > destruct an AST node, assume a wrapper node inside (add an extra > case), or use the smart constructors/pattern synonyms. Aha! This, I did not know. So, you're saying

Re: Performance of pattern synonyms

> On Feb 11, 2019, at 8:55 AM, Simon Peyton Jones wrote: > > What exactly is “the alternative compile-time implementation”? In my response, I interpreted this to be macro-expansion, the alternative we discuss in the paper. The paper includes a nice discussion of how the semantics differs

Re: Commit comments - call for opinions

I personally prefer seeing the whole commit message, if only because including it is more prominent than just a mention. Commits are really important, and should be made to stand out beyond just a mention. Not sure if this is worth yet more custom tooling, though. Richard > On Feb 8, 2019, at

Re: Scaling back CI (for now)?

So, just checking: is the recommended route to merging now to use the Marge Bot instructions posted previously? (That is, get 1+ approvals and then assign to Marge.) Thanks, Richard > On Feb 6, 2019, at 5:23 PM, Ben Gamari wrote: > > Phyx writes: > >> That aside, the CIs don't seem stable

CI request: a DEBUG compiler

Hi devs, I almost exclusively work with a DEBUG compiler. It continually shocks me that I'm relatively alone in this stance, as the ASSERTs littered throughout GHC have caught many a bug in easier a manner than long stares at -ddump-tc-trace would do. In any case, my goal in this email is not

Re: Hadrian questions

t; > The `hadrian/build.sh` script uses `cabal new-build` so the > dependencies should be shared already when possible. > > Cheers, > > Matt > > On Fri, Jan 25, 2019 at 4:07 AM Richard Eisenberg > wrote: >> >> In the "devel2" flavor, I also seem

Marge: "CI is taking too long"

Marge has complained that https://gitlab.haskell.org/rae/ghc/-/jobs/17206 is taking too long. And indeed it seems stuck. Help? Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are nested brackets disallowed?

` like normal. > > 4. x is defined in stage 2 and used in stage 1 > > foo = [| [| \x -> $(x) |] |] > > Rejected just like usual. `x` won't be bound when the splice is run. > > It seems that with some suitable care that things will work out when > lifting across multip

Re: Hadrian questions

In the "devel2" flavor, I also seem to have built Haddock. `make` didn't do this with devel2, and I'd prefer Hadrian didn't, too. Maybe I'm not really on the devel2 flavor? > On Jan 24, 2019, at 11:02 PM, Richard Eisenberg wrote: > > As suggested, I'm trying out Ha

Hadrian questions

As suggested, I'm trying out Hadrian. I have a few questions. - After building GHC the first time, I often go into the /ghc directory and then do `make 2` to build just the stage-2 compiler. Is that now the same as `build --freeze1`? It would seem not (I haven't tested), because running `make

Re: "resource exhausted" in CI

Ah, yes -- I did push a rebase. OK: good to know that this is expected behavior after rebasing (makes sense). Thanks, Richard > On Jan 24, 2019, at 2:01 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >> Something is awry: https://gitlab.haskell.org/rae/ghc/-/jo

access failed CI artifacts

A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807 The failures are just some output changes. I could delicately use the log to extract the changes and commit them, but it would be better to have direct access to, say, the *.run.stderr files and then commit those. Is

"resource exhausted" in CI

Hi Ben, The pipeline for a recent patch (https://gitlab.haskell.org/rae/ghc/-/jobs/16793) says: HC [stage 1] compiler/stage2/build/TcForeign.o HC [stage 1] compiler/stage2/build/TcRules.o /tmp/ghc6477_0/ghc_3.s: hClose: resource exhausted (No space left on device) compiler/ghc.mk:445:

Re: Why are nested brackets disallowed?

I think Geoff was primarily concerned with typed Template Haskell, not the untyped variety. I, too, have wondered if there was a technical reason behind this restriction, or if merely it was assumed that nested brackets were not worthwhile. One question: how would staging work between nesting

Re: MR does not merge

+1 on Simon's plan. I explicitly agree with the move not to validate before the final commit (if a rebase is necessary); note that the successful rebase is guaranteed not to have any conflicts (or else step 3 would have failed). We should continue to do CI on the commits that have actually

Re: GHC | Some refactoring in tcInferApps (!116)

I confirm that I see "Unresolve discussion" buttons in the "Discussion" page, after "Toggle Discussion" is clicked. Perhaps we have this working convention: the dev that starts the discussion is expected to resolve it. I doubt GL can enforce that convention, but we can just agree to it all.

Re: Reviews

> On Jan 11, 2019, at 4:49 AM, Simon Peyton Jones wrote: > > When I try that, it starts by displaying the code from the file. No rotating > circles or anything. But if I wait ten seconds, suddenly the comments appear. > So: > rendering seems terribly slow > there is no indication that it

Re: Reviews

While we're whinging: - I'm looking at the Discussion page for an MR (https://gitlab.haskell.org/ghc/ghc/merge_requests/74#note_1904) and I see a comment Simon made, beginning with "No, I am not!". I wanted a bit more context. So I click on the filename above the Discussion and am warped to

Re: FYI panic "flatten_args wandered into deeper water than usual"

I suspect that you spent a good deal of time in search of this knowledge. Is there something in this code that could have helped you do this faster? Unfortunately, the water in flatten_args is indeed deep, and I don't think there's any way to fix that. I've considered writing a peer-reviewed

Re: GitLab cross-posting to Trac?

atically, it must be done manually by each person >> making a commit. Which is terribly painful. (esp since it can only be done >> post-CI.) >> >> Thanks >> >> Simon >> >> | -Original Message----- >> | From: ghc-devs On Behalf Of Ben Gamari >

Re: GitLab: Cmd+Enter considered harmful on reviews

. Richard > On Jan 4, 2019, at 1:09 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >> PSA: When reviewing an MR on GitLab, every comment has two buttons: >> (1) add to review, and (2) add comment now. Cmd+Enter (on my machine >> at least), does option (2),

GitLab: Cmd+Enter considered harmful on reviews

PSA: When reviewing an MR on GitLab, every comment has two buttons: (1) add to review, and (2) add comment now. Cmd+Enter (on my machine at least), does option (2), even though option (1) is bold and green. This is not what I wanted. (By the way, "comments" actually open these things called

Re: Gitlab pain

GitLab groups posts on lines in MRs as "discussions". A discussion can be *resolved*. When it is resolved, the discussion is collapsed by default when you view the MR. The particular comment you're seeking can be found on the MR if you open the discussion you started at 10:04am this morning

GitLab cross-posting to Trac?

Hi devs, With our new GitLab workflow, will commit messages still be posted to Issues (once the migration is complete)? That's been really useful with Trac. Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org

Re: [GHC DevOps Group] GitLab migration status

> On Dec 17, 2018, at 10:52 AM, Ben Gamari wrote: > >> >> - What will happen to Phabricator diffs that are still mid-review? It would >> be a shame to have to move them to gitlab and interrupt the review trail. >> Can't we just shut Phabricator to new diffs but keep the possibility of >>

Re: Cabal not updated after rebase?

On Dec 3, 2018, at 6:27 PM, My Nguyen wrote: > > I did not touch Cabal at all, but somehow `git status` in libraries/Cabal is > telling me there’s a detached HEAD? > > I built GHC with a fresh checkout from github, and it worked. But after > applying my patch, it doesn’t wor

Re: Cabal not updated after rebase?

Did you change the Cabal submodule at all in your work? Maybe it's out of sync somehow... What happens if you build GHC without including your changes? Does it work? > On Dec 3, 2018, at 12:13 PM, My Nguyen wrote: > > Hello, > > Thanks for the suggestion. Unfortunately, the problem persists

Re: slow execution of built executables on a Mac

e and maybe > dtrace or even time. > > Cheers > George > > > > On Sat, Nov 10, 2018 at 11:10 PM Ben Gamari <mailto:b...@well-typed.com>> wrote: > Richard Eisenberg mailto:r...@cs.brynmawr.edu>> writes: > > > OK. Well, I couldn't sample f

Re: slow execution of built executables on a Mac

f the top of the activity monitor. It > also shows cpu times which may be helpful. > > On Wed, Nov 7, 2018 at 7:10 PM Ben Gamari <mailto:b...@well-typed.com>> wrote: > Richard Eisenberg mailto:r...@cs.brynmawr.edu>> writes: > > > Sadly, none of the su

Re: slow execution of built executables on a Mac

30, 2018, at 2:32 PM, Gabor Greif wrote: > > Maybe a symptom of an AFPS bug? > https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/ > > Just came across this, might be worth a look. > > Cheers, > >Gabor > > On 10/26/18, Richard Eisenbe

Re: [GHC DevOps Group] The future of Phabricator

> On Nov 3, 2018, at 9:17 AM, Alan & Kim Zimmerman wrote: > > As part of the silent bystander grouping, I just want to voice a weak ok for > switching to gitlab, +1 to this exact sentiment from me, and for the same reasons Alan voiced. I have a horse in this race and care about the outcome,

Re: Visible dependent quantification / CUSKs

Feared as much. I'd love for these to be implemented and was excited to see them listed! I do expect to implement these some day. But certainly not for 8.8. Thanks, Richard > On Nov 2, 2018, at 1:00 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >> Hi all, &g

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

> On Oct 26, 2018, at 9:43 PM, Carter Schonwald > wrote: > > ORDER of the abstracted constructors matters! That's a very good point. So we don't have a set of sets -- we have a set of lists (where normal constructors -- which have no overlap -- would appear in the lists in every possible

Visible dependent quantification / CUSKs

Hi all, I see visible dependent quantification and top-level kind signatures on the release plan for GHC 8.8. Is there a diff for these I've missed? Or is something in the works? Sorry if I've just missed it go by! Thanks, Richard ___ ghc-devs

Re: slow execution of built executables on a Mac

> On Oct 26, 2018, at 5:02 PM, Carter Schonwald > wrote: > > are you setting the intree gmp flag? and/or dont have gmp the library > installed? maybe your ghc is using integer simple! Intriguing possibility. I haven't done anything to install gmp. I'm now at home, away from this machine,

slow execution of built executables on a Mac

Hi devs, I have a shiny, new iMac in my office. It's thus frustrating that it takes my iMac longer to build GHC than my trusty 28-month-old laptop. Building devel2 on a fresh checkout takes just about an hour. By contrast, my laptop is done after 30 minutes of work (same build settings). The

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

TE pragmas to support polymorphism, maybe we could support this too. > The idea is to build a different set of conlikes depending on the matched > type. Pseudo-code: > instance Complete (Variant cs) where > conlikes = [V @c | c <- cs] -- cs is a type list > (I don't really care abou

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

I'm afraid I don't understand what your new syntax means. And, while I know it doesn't work today, what's wrong (in theory) with {-# COMPLETE LL #-} No types! (That's a rare thing for me to extol...) I feel I must be missing something here. Thanks, Richard > On Oct 25, 2018, at 12:24 PM,

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

In a rare move, I disagree with Ryan here. Why don't we want LL to be abstract? I personally don't want to be thinking of some desugaring to a view pattern when I say LL. I want just to be pattern matching. Is there a reason we can't extend COMPLETE pragmas to cover this case? Richard > On

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

This sounds like an infelicity in COMPLETE pragmas. Do we have a documented reason why fixing this is impossible? Richard > On Oct 25, 2018, at 7:36 AM, Shayan Najd wrote: > > Dear GHC hackers, > > On our work on the new front-end AST for GHC [0] based on TTG [1], we > would like to use a

Re: Treatment of unknown pragmas

> On Oct 17, 2018, at 10:22 AM, Simon Marlow wrote: > > but then nothing wil notice if you say {-# TOOL HLNIT ... #-} by mistak This seems fixable. Any tool can slurp in all `TOOL` (or `X-`, which I prefer) pragmas and look for ones that appear to be misspellings. Of course, this doesn't

Re: Parser.y rewrite with parser combinators

I think one problem is that we don't even have bounded levels of backtracking, because (with view patterns) you can put expressions into patterns. Consider > f = do K x (z -> ... Do we have a constructor pattern with a view pattern inside it? Or do we have an expression with a required

Re: Parser.y rewrite with parser combinators

I, too, have wondered about this. A pair of students this summer were working on merging the type-level and term-level parsers, in preparation for, e.g., visible dependent quantification in terms (not to mention dependent types). If successful, this would have been an entirely internal

Re: Shall we make -dsuppress-uniques default?

I'm in the opposite camp. More often than not, the biggest advantage of dumps during GHC development is to see the uniques. Indeed, I often ignore the actual names of variables and just work in my head with the uniques. Perhaps the more complete answer is to fine-tune what settings cause the

Re: Unpacking coercions

I don't think that wiki reference is really about this problem. Instead, I think that we'd need Constraint# to be able to offer users ~# and ~R#. The problem, then, is that there is no answer to this question: Constraint is to Type as Constraint# is to what? Currently, if ~# and ~R# are the

Re: [ANNOUNCE] GHC 8.6.1-beta1 available

> On Aug 11, 2018, at 11:27 AM, Vassil Ognyanov Keremidchiev > wrote: > > What are the new features there toward Dependent Typed Haskell? Ben's link to https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/8.6.1-notes.html

Re: submodule repos on GitHub

it clone --recursive git://git.haskell.org/ghc.git > }}} > > > Matt > > On Tue, Jul 17, 2018 at 10:04 PM, Artem Pelenitsyn > wrote: >> I personally consider this to be most reasonable. But maybe I oversee >> something… >> >> -- >> Best, Artem >

Re: submodule repos on GitHub

; Did you do the line above as well? > > ``` > git config --global url."git://github.com/ghc/packages-".insteadOf > git://github.com/ghc/packages/ > ``` > > On Tue, Jul 17, 2018 at 8:09 PM, Richard Eisenberg > wrote: >> Hi devs, >> >> The

submodule repos on GitHub

Hi devs, The Newcomers page (https://ghc.haskell.org/trac/ghc/wiki/Newcomers) recommends cloning GHC with > git clone --recursive git://github.com/ghc/ghc I believe my students did this with success several weeks ago. But trying it again today leads to trouble with some submodules, e.g.: >

Re: #10789

up to return diagnostic information if a match fails. (I would look at reduceTyFamApp_maybe, and perhaps it can return something more interesting than Nothing in the failure case.) > > Richard Eisenberg offered some help on this but I am not sure how to grab > hold of him so I'd apprecia

<    1   2   3   4   5   6   7   8   9   >