Re: -ddump-json

schema for the JSON dumps? > > On 29/01/2021 09:57, Matthew Pickering wrote: >> Just grepping Github there appears to be a few users of the flag but >> no more than a handful. I think you can probably change it how you >> like. >> >> Cheers, >> >>

-ddump-json

Hi devs, In my work with Alfredo at revising our error message infrastructure, we ran across some code that renders error messages as JSON. Given that our data structures are changing, it seems natural to change the JSON output, too, but it's unclear whether that's wise. The manual currently li

safe to upgrade my Mac?

Hi devs, I'm currently running MacOS High Sierra, 10.13.6. Things are fine, but I'd like to upgrade to get Dark Mode and (hopefully) to speed up Mail. (That is, upgrading is nice, but not at all necessary.) If I upgrade, will GHC hate me? That is, will GHC 8.10 continue to work? Will I continu

Re: Lexing / Parsing and final token

nging it to remove the final ';' gives a last token of ITccurly. > > Changing it to > > module Bug where > x = 5 > y = 6 > > Gives a last token of ITsemi. > > Alan > > On Tue, 19 Jan 2021 at 21:50, Richard Eisenberg <mailto:r...@richarde.dev>&g

Re: Lexing / Parsing and final token

That's bizarre. Does it still happen with explicit braces? Just to test, I tried module Bug where { x = 5; y = 6; }; and GHC rejected because of the trailing ;. Richard > On Jan 19, 2021, at 4:35 PM, Alan & Kim Zimmerman wrote: > > I am (still) working on !2418 to bring the API Annotations i

Re: can't get raw logs -- server down?

> > Hope that helps. > > Merry Christmas :) > Sebastian > > Am Do., 24. Dez. 2020 um 17:38 Uhr schrieb Richard Eisenberg > mailto:r...@richarde.dev>>: > Hi devs, > > I have a failing CI run at https://gitlab.haskell.org/ghc/ghc/-/jobs/533674 > <https://gitlab.h

can't get raw logs -- server down?

Hi devs, I have a failing CI run at https://gitlab.haskell.org/ghc/ghc/-/jobs/533674 . I can't repro the problem locally, so I wanted to see the raw log. But clicking the raw log button (leading to https://gitlab.haskell.org/ghc/ghc/-/jobs/53367

Re: Troubles when building ghc

Without having particular knowledge about this specific error: try upgrading `alex`, the tool that GHC uses to produce its lexer. It's possible a newer version of that tool will fix this problem. Richard > On Dec 23, 2020, at 1:37 PM, Neophytos Michael wrote: > > I am having some trouble buil

Help lead Haskell: Executive Director sought for Haskell Foundation

Posting on behalf of the Haskell Foundation Working Group. Please forward widely! The Haskell Foundation is seeking an Executive Director. Please find the job description here: https://haskell.foundation/ ed-job-description

Re: Use of forall as a sigil

> On Dec 3, 2020, at 11:11 AM, Bryan Richter wrote: > > I must be confused, because it sounds like you are contradicting yourself. :) > In one sentence you say that there is no assumed universal quantification > going on, and in the next you say that the function does indeed work for all > t

Re: Use of forall as a sigil

> On Dec 3, 2020, at 10:23 AM, Bryan Richter wrote: > > Consider `forall a -> a -> a`. There's still an implicit universal > quantification that is assumed, right? No, there isn't, and I think this is the central point of confusion. A function of type `forall a -> a -> a` does work for all t

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

> On Nov 30, 2020, at 3:50 PM, Christiaan Baaij > wrote: > > It seems like a function like `rewritePlugin` is something we could/should > just build on top of the existing plugin mechanism, and have something along > the line of: > > > -- | Create a 'TcPluginSolver' from the provided rewrit

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

some other state passed in (including other constraints, if there is demand). The tycon would always be a type family, and the types would always exactly saturate the type family. Then, the plugin could reduce the type family if it knows how to do so. This seems to be a fairly simple interface and would be v

Re: Adding a way to reduce type families in type errors

> On Nov 21, 2020, at 10:38 PM, Jakob Brünker wrote: > > Three questions: > - Is there already a way to do this that I'm missing? Not that I'm aware of. GHC sometimes expands type families and sometimes doesn't. The general philosophy has been that expanding type families is usually good an

Re: Questions about System F and data types

> On Nov 22, 2020, at 6:49 AM, Jan van Brügge wrote: > To better understand PL papers, especially those involving System Fc and its > extensions, I started to write a formal proof of type safety including > alpha-equivalence. Currently I have a complete proof for System F >

Re: Use of forall as a sigil

s, > Andrey > > -Original Message- > From: John Ericson [mailto:john.ericson@obsidian.systems] > Sent: 22 November 2020 16:41 > To: Andrey Mokhov ; Richard Eisenberg > > Cc: ghc-devs@haskell.org > Subject: Re: Use of forall as a sigil > > > I have

Re: Use of forall as a sigil

>> wrote: >>> >>> Semantically, `forall a -> a -> Int` is the same as `forall a. a -> Int`. >>> The two only differ in how you use them: >>> * For the first one, you have to explicitly provide the type to use for >>> `a` at

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

s/src/GHC.TcPluginM.Extra.html#flattenGivens > > <https://hackage.haskell.org/package/ghc-tcplugins-extra-0.4/docs/src/GHC.TcPluginM.Extra.html#flattenGivens> > Which I use in all of my plugins. (PS it should perhaps be called > "unflattenGiven"? like I said, I alwa

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

tenGiven"? like I said, I always get confused about flatten vs > unflatten). Yes, this would be unflattening. Glad to know this would work well with your plugins. :) Richard > > On Thu, 19 Nov 2020 at 05:20, Richard Eisenberg <mailto:r...@richarde.dev>> wrote: > Hi all

Re: PSA: type checker plugins to be affected by upcoming changes to GHC

> On Nov 19, 2020, at 4:14 AM, Adam Gundry wrote: > > As part of removing Deriveds, do you plan to change the type-checker > plugin interface to drop the redundant argument? Although I suppose GHC > could simply pass an empty list to the plugin. No -- I think we'll just remove the unused param

PSA: type checker plugins to be affected by upcoming changes to GHC

Hi all, I'm hard at work on two significant refactorings within GHC's constraint solver. The first is at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4149. It removes flattening meta-variables and flattening skolems. This is a very nice simplification. Instead, it just reduces type fami

Re: Use of forall as a sigil

Hi Bryan, First off, sorry if my first response was a bit snippy -- it wasn't meant to be, and I appreciate the angle you're taking in your question. I just didn't understand it! This second question is easier to answer. I say "forall a arrow a arrow Int". But I still think there may be a deep

Re: Use of forall as a sigil

Hi Bryan, I don't think I understand what you're getting at here. The difference between `forall b .` and `forall b ->` is only that the choice of b must be made explicit. Importantly, a function of type e.g. `forall b -> b -> b` can *not* pattern-match on the choice of type; it can bind a vari

Searching on GitLab

Hi all, Some time ago, I set up a keyword bookmark (https://www-archive.mozilla.org/docs/end-user/keywords.html ) to search in tickets and MRs, by using a Google "site:gitlab.haskell.org/ghc/ghc/issues/

Re: Status of #10071 (class method deprecations)

My take (not authoritative) is that some good ideas were floated, but nothing was decided on. Given that we now have a proper process for deciding on new features, I think we should use it, and go via a proposal. Note that I've fixed the link in the original description to point to https://gitl

Announcing the Haskell Foundation

I'm very pleased to announce the creation of the Haskell Foundation (HF), an independent, non-profit organisation dedicated to broadening Haskell adoption. Website: https://haskell.foundation/ Twitter: @haskellfound Founding whitepaper: https://haskell.foundation/whi

Tomorrow: Simon PJ announces Haskell Foundation

Tomorrow (Wednesday Nov 4) at 12:00 UTC, Simon PJ will announce the formation of the Haskell Foundation, an independent, non-profit organization dedicated to broadening Haskell adoption. This will be a part of Haskell eXchange, but this announcement will be free to attend, via YouTube. Much of t

Re: GitLab down

> On Oct 23, 2020, at 10:05 AM, Ben Gamari wrote: > > GitLab is back up and notification email has been restored. I'm seeing new emails -- thanks. Should we expect to get the notifications that weren't delivered yesterday? Thanks! Richard___ ghc-de

Re: GitLab e-mails: down for everyone, or just me?

I, too, have received no notifications at all from GitLab. Richard > On Oct 22, 2020, at 7:34 AM, Ryan Scott wrote: > > Since yesterday, I haven't been receiving any e-mail notifications from > GitLab. Are other people having this problem too, or is it a problem on my > end? > > Ryan S. > __

Re: !RE: Implicit reboxing of unboxed tuple in let-patterns

This whole area is clearly somewhat troublesome: > On Sep 10, 2020, at 12:05 PM, Iavor Diatchki wrote: > > 3. nested bang patterns in pattern bindings should count as "uses" of the > value and therefore should be strict. For example if I write `let ( !x, !y ) > = undefined in ()`, I think thi

Re: Implicit reboxing of unboxed tuple in let-patterns

ption would be to make it an error to use a lazy > pattern on an unlifted type, and require programmers to manually add the `!` > but I am not sure that gains much, and is more work in the compiler. > > -Iavor > > On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <m

Re: Implicit reboxing of unboxed tuple in let-patterns

> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud wrote: > > This is all a tad tricky, I must say. ... which is one of the reasons I originally wanted one simple rule. I'm not now saying I was in the right, but it is an attractive resting point for this discussion. To be clear, I don't think t

Re: GHC Logo

2020, at 10:16 AM, Richard Eisenberg wrote: > > I'm oddly drawn to the idea of a turtle -- except that turtles are slow. But > animals are cute. Maybe something involving a fox, given that foxes can be > clever? Octopuses are also known to be very clever, but maybe GitHub has &

Re: GHC Logo

I'm oddly drawn to the idea of a turtle -- except that turtles are slow. But animals are cute. Maybe something involving a fox, given that foxes can be clever? Octopuses are also known to be very clever, but maybe GitHub has octopuses covered. > On Sep 1, 2020, at 8:42 PM, Carter Schonwald >

Re: Implicit reboxing of unboxed tuple in let-patterns

> On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud wrote: > > Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know > what the semantics of these ought to be. It does look like an interesting can > of worms. How do they currently desugar? Right now, there is one rule: if the t

Re: GHC Logo

Late to the party here, but I'm wondering whether we can enlist someone with graphic design experience to create a more iconic logo for the compiler. I use the word "iconic" deliberately: it should both be recognizable, and in the shape of an icon (that is, more square). The Haskell logo does th

Re: COMPLETE pragmas

look at the pattern-match as a whole and use the pattern synonym to find the relevant COMPLETE set(s). Thanks for taking a look! Richard > On Aug 31, 2020, at 4:23 PM, Sebastian Graf wrote: > > Hi Richard, > > Am Mo., 31. Aug. 2020 um 21:30 Uhr schrieb Richard Eisenb

Re: HsPragTick

I'm content with ripping it out and waiting to see if anyone complains. Without documentation or any obvious users, it seems hard to do otherwise. That said, if you reading this have a better idea than we do about who uses {-# GENERATED ... #-} pragmas, do speak up! Thanks, Richard > On Aug 31

COMPLETE pragmas

Hi Sebastian, I enjoyed your presentation last week at ICFP! This thread (https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms) played out before you became so interested in pattern-match coverage. I'd be curious

Re: Implicit reboxing of unboxed tuple in let-patterns

> On Aug 31, 2020, at 10:34 AM, Spiwack, Arnaud wrote: > > That being said, Richard seemed to feel rather strongly about this one. > Richard, do you still agree with your then position that let (#x, y#) = … > being a lazy pattern (hence implicitly boxes the pair) is the right semantics? I ad

Re: Hi. I'm new to this mailing list and have a few questions.

-> (b, [String]) > > This wouldn’t break any existing programs since using record syntax here is > already disallowed and met with an error message. > > A question is of course the symbol used for assignment (~, =, ::, or ->?). > > > I hope the code shows up as a

Re: Hi. I'm new to this mailing list and have a few questions.

Hi Anselm, Welcome! A good way of getting used to a list like this one is to wait a little while and observe what kind of messages others send; this will give you a feel for how the list is used. If you're impatient, you can also check out the archives at https://mail.haskell.org/pipermail/ghc

Re: How should we treat changes to the GHC API?

> On Jul 27, 2020, at 5:24 PM, John Ericson > wrote: > > As permanent solution I don't like it, but as a stop gap to relieve any > pressure for stability until we have sane interfaces, I *love* it. I guess I'm arguing that ghc-lib (or something like it) should be the permanent solution. GHC

Re: How should we treat changes to the GHC API?

> On Jul 27, 2020, at 2:07 PM, Eric Seidel wrote: > > a stronger focus on API stability and perhaps a broader view of what > constitutes (or should be included in) the public-facing API would be welcome! I agree with this in the abstract, but I'm not sure about agreeing with it in the concre

Re: Error messages

I agree that good error messages are crucial. I also agree that it can be hard for new feature designers to anticipate all the ways things might go wrong, and you've hit several bumps here. I've filed https://gitlab.haskell.org/ghc/ghc/-/issues/18466, which observes how painful this can be and

perf regression with TypeFamilies

Hi Harendra, I saw your comment on a ghc proposal (https://github.com/ghc-proposals/ghc-proposals/pull/343#issuecomment-650797297) that said you experienced perf regressions with -XTypeFamilies enabled (but no other changes). Are these reproducible in a way that can be shared publicly? And are

IP/key change for gitlab.haskell.org?

An innocent `git push` yielded this today: @@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@ The ED25519 host key for gitlab.haskell.org has changed, and the key for th

Re: Search in GitLab

> On Jun 15, 2020, at 6:50 PM, Ben Gamari wrote: > > Richard, I checked on Google Search Console and it appears to be > indexed on a nearly-daily basis. I'm a bit surprised that you have been > having trouble. Do you have a specific example of a query that you have > been disappointed by in the

Re: Search in GitLab

I've used the site:gitlab.haskell.org trick on Google for some time. Recently (last month or so?) I've found that it's much less useful. I can't quantify this, other than the fact that I find myself frequently displeased with the result. It does seem that Google indexes our site less frequently

Re: profiling a constructor?

Not hard to > add either. > > (Richard is asking for number of allocations, not what is live at any moment.) > > Simon > > | -Original Message- > | From: ghc-devs On Behalf Of Richard > | Eisenberg > | Sent: 23 May 2020 13:59 > | To: GHC developer

profiling a constructor?

Hi devs, Is there a way to count the number of times a particular constructor is allocated? I might want to know, say, the total number of cons cells allocated over the course of a program, or (in my actual case) the total number of FunTy cells allocated over the course of a program. I can try

Re: GitLab is down ?

and it's back! Yay! Richard > On May 19, 2020, at 11:42 AM, Richard Eisenberg wrote: > > Hi devs, > > gitlab.haskell.org is reporting an error 500. :( > > Help? > > Thanks! > Richard > ___ > ghc-devs m

GitLab is down ?

Hi devs, gitlab.haskell.org is reporting an error 500. :( Help? Thanks! Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Removal of UniqMap module

> On May 10, 2020, at 11:22 AM, Matthew Pickering > wrote: > > Hi, > > I noticed that the UniqMap module was removed from the tree > > See 1c7c6f1afc8e7f7ba5d256780bc9d5bb5f3e7601 > > Why was it removed? From the commit message: "This module isn't used anywhere in GHC." That seems like a

Re: Expanding a particular type family in type errors

> On May 4, 2020, at 8:17 PM, Alexis King wrote: > >> 3. reportWanteds will have a similar problem: if we have >> -fdefer-type-errors, then reportWanteds may actually happen before >> desugaring and execution, and we can't have a type magically changed in the >> process. Doing so will lead t

Re: Expanding a particular type family in type errors

I'm afraid I like none of (1)-(5). Important background: if we have type family F a where F Int = Bool, then F Int and Bool are *not* equal in Core. We cannot just change one to the other. Instead, a coercion exists between them. 1. pprType seems a very challenging place to do this, given that p

Re: Why doesn’t the simple optimizer fuse casts?

> On Apr 28, 2020, at 1:07 AM, Ben Gamari wrote: > > Sounds like it would be worth a quick try. I agree with Ben. I generally expect not to see nested casts -- the Cast constructor should rarely (never?) appear as an expression outside of mkCast. But you're right about the missing optimizati

Re: Why doesn’t the simple optimizer fuse casts?

Hi Alexis, Nested casts shouldn't happen. The mkCast function gets rid of them. Someone somewhere is forgetting to call it. If you have a concrete program that leads to nested casts, post a bug report. :) Thanks! Richard > On Apr 27, 2020, at 8:29 PM, Alexis King wrote: > > This question is

Re: Measuring compiler performance

Because of the fragility of time-based performance tests, I often use allocations as a proxy for time. The number of allocations is very stable. On the down side, it is sometimes possible to reduce allocations while increasing time, so one shouldn't try too hard to blindly optimize allocations.

Re: Module Renaming: GHC.Core.Op

I would vote against the GHC.Core.Types directory, because there is the potential for confusion with "types we are declaring" to "this stuff is about Haskell types". As I've posted elsewhere, I'm in strong support of separating definitions about Core from operations on Core. Originally, I though

Re: Getting the inferred types of TH's UnboundVarEs

> On Mar 19, 2020, at 5:31 PM, Sandy Maguire wrote: > > The world will be a much better place when TTG is finished and we have > ghc-as-an-easy-to-use-library As much as any software is ever "finished", I'd say TTG is finished. That is, I think the structure is ready for us to consider e.g.

Re: Getting the inferred types of TH's UnboundVarEs

Good to see you around, Sandy! > On Mar 18, 2020, at 6:54 PM, Sandy Maguire wrote: > > I mean if `insert :: a -> Container a -> Container a`, and I call it with > `[e| insert 5 True |]`, the quote will fail. I don't observe this. Specifically, when I compile > {-# LANGUAGE TemplateHaskellQuot

Re: intent to enable 2fa requirement for github.com/haskell org

> On Mar 18, 2020, at 11:52 PM, Carter Schonwald > wrote: > > After talking with several folks, feedback has been that best practices are > to make sure the notice is a week before hand. > > So what I’ll do is personally reach out to those who aren’t 2fa enabled in > the Haskell gh org (an

Re: performance testing

e is a wiki > page that may help: > https://gitlab.haskell.org/ghc/ghc/wikis/building/running-tests/performance-tests. > Let me know if that's not sufficiently helpful. > > David E > > On 3/10/20 11:05 PM, Richard Eisenberg wrote: >> Hi all, >> >> I'm

performance testing

Hi all, I'm very confused by how to do performance testing. I have a patch that seems to cause a performance regression. So I built the patch locally (`validate` flavor, with `make`) and then reproduced the regression. Good. Then, I make a small change, rebuild, commit, and then test. But now

Re: ADT arguments and Levity Polymorphism

> On Feb 10, 2020, at 8:48 PM, Csaba Hruska wrote: > > Hello, > > Are heap stored ADT's arguments always levity (representation) monomorphic? Yes. > (I guess they are otherwise the info table would not be a constant value > instead it would be a function that calculates the representation d

Re: Request for two new MR-labels: "review-needed" and "changes-required"

Hi Ben, Thanks for reminding me about that document. Has it been officially ratified as our procedure of record? My guess is "no". What's it waiting on? That document has been around for quite some time now. Thanks, Richard > On Feb 7, 2020, at 9:32 PM, Ben Gamari wrote: > > Andreas Klebinge

Re: gaining access to the `ghc` group

> > I have updated the instructions on the submodules wiki page to reflect > this new feature. Does this look better? Perfect. Thank you! ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: more submodule questions

> On Jan 27, 2020, at 8:19 PM, Ben Gamari wrote: > > The linter does not hold up builds for merge requests but will hold up a > "pre-merge" validation job (e.g. a validation of an MR created by > @marge-bot). This ensures that a patch containing a wip/ submodule > reference will not be merged t

gaining access to the `ghc` group

Hi devs, I'm onboarding a new contributor (Gert-Jan Bottu), whose patch (!2465) makes commensurate changes in Haddock. In order to use CI, then, he needs to be able to push a wip/ branch to our fork of Haddock. In order to do that, he needs to be in the `ghc` group. (I'm assuming -- but have no

more submodule questions

Hi devs, I recently found this text at the end of https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules : --- The CI pipeline of ghc/ghc> includes a linting step to ensure that all submodules

Re: How to turn LHExpr GhcPs into CoreExpr

gt;> I would also support adding any missing functions to GHC-the-library to make >> this possible if any turn out to be required. >> >> As an alternative you could also use the GHCi approach of using a fake >> Module. This would allow you to copy whatever GHCi is doing. &

Re: How to turn LHExpr GhcPs into CoreExpr

You'll need to run the expression through the whole pipeline. 1. Parsing 2. Renaming 3. Type-checking 3a. Constraint generation 3b. Constraint solving 3c. Zonking 4. Desugaring I don't have the exact calls you should use for these steps, but I can give you some pointers. 1. parseExpressio

Re: submodule instructions?

Great -- thanks. I think it's all clarified now. Richard > On Jan 20, 2020, at 4:34 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >>> On Jan 17, 2020, at 9:15 PM, Ben Gamari wrote: >>> >>> I have added a bit of language to [submo

Re: is Unlifted Type == Primitive Type?

The recent addition of -XUnliftedNewtypes means that user-defined newtypes (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0098-unlifted-newtypes.rst ) can indeed be unlifted a

Re: submodule instructions?

> On Jan 17, 2020, at 9:15 PM, Ben Gamari wrote: > > I have added a bit of language to [submodules] explaining how to > accomplish this. Very helpful -- thanks. A few questions (preferably answered directly on the wiki page): - Who is the `ghc` group and how does one join this group (is ther

submodule instructions?

Hi devs, Are there up-to-date instructions on how to deal with submodules in GHC? https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git/submodules does give nice information. It refers to https://gitlab.ha

Re: Fixing type synonyms to Uniq(D)FM newtypes

One advantage of the phantom-parameter approach is that it allows for nice polymorphism. > lookupEnv :: Uniquable dom => UniqFM dom rng -> dom -> Maybe rng Now, we don't need lookupVarEnv separately from lookupNameEnv, but we get the type-checking for free. I agree with Ben about the fact that

Re: Fixing type synonyms to Uniq(D)FM newtypes

I'd be fine with making these newtypes, but I still don't quite understand the motivation. Note that the specialized functions for the different instances of UniqFM all have type signatures. For example, delVarEnv will only work with a Var, not a Name. Was there a different scenario that you wa

Re: Extension.hs ForallXXX constraints

Somehow, I remember this conversation coming up recently, and I thought it was decided to remove these. Indeed, I'm surprised they're still around. Strike them down! Thanks, Richard > On Jan 8, 2020, at 10:38 PM, Alan & Kim Zimmerman wrote: > > I have got back into some GHC dev, and noticed t

Re: Superclasses of type families returning constraints?

> On Jan 6, 2020, at 2:52 PM, Simon Peyton Jones via ghc-devs > wrote: > > | type family F a b :: Constraint where > | F a a = () > | > | eq :: F a b => a :~: b > | eq = Refl > > This is rejected, and it's not in the least bit puzzling! You have evidence > for (F a b) and

Re: Superclasses of type families returning constraints?

encode these partial improvements, and then work on changing Core. That road seems too long, though, so in the end, I think constrained type families (with superclass constraints) might be a more fruitful direction. Richard > On Jan 5, 2020, at 6:02 PM, Alexis King wrote: > >> O

Re: help understanding a ghc assert failure wrt coercions

> On Jan 6, 2020, at 4:44 AM, Ben Gamari wrote: > Try adding -dppr-debug to your command line. This may reveal the difference. Also, I recommend `-fprint-explicit-kinds -fprint-explicit-coercions -fprint-typechecker-elaboration -fprint-explicit-runtime-reps -fprint-explicit-foralls` just for

Re: hadrian-util: An experiment in a more usable hadrian UX

This looks really useful, and might bridge the gap between the UX I'm used to and Hadrian, allowing me to adopt Hadrian sooner than I otherwise would. However, I would be disappointed to see hadrian-util still in active use when `make` is removed (#17527). I'm glad to see Ben's %Make removal mil

Re: Superclasses of type families returning constraints?

> On Dec 30, 2019, at 11:16 AM, Alexis King wrote: > > I don’t know if there is a way to encode those using the constraint language > available in source Haskell today. I gave it a good try, but failed. The trick I was hoping to leverage was *partial improvement*. Here is an example of parti

Re: A small but useful tool for performance characterisation

Hi Ben, This sounds great. Is there a place on the wiki to catalog tools like this? Thanks for telling us about it! Richard > On Jan 4, 2020, at 7:37 PM, Ben Gamari wrote: > > Hi everyone, > > I have recently been doing a fair amount of performance characterisation > and have long wanted a co

Re: Implementation of Type level warnings

I've responded on the MR. Thanks for stepping up to do this! Richard > On Dec 30, 2019, at 5:53 AM, Rowan Goemans wrote: > > Hello everyone, > > A couple of days ago I tried to implement type level warnings [1]. I have got > something > now that sort of works but issues the same warning multi

Re: Superclasses of type families returning constraints?

Hi Alexis, I'm not aware of any work in this direction. It's an interesting idea to think about. A few such disconnected thoughts: - You could refactor the type family equation to be `F a b = a ~ b`. Then your program would be accepted. And -- assuming the more sophisticated example is also of

GitLab # trick

Today I learned that if you type # in an input field on GitLab, you can start typing the description of a ticket, and GitLab will find the number of the (open) ticket for you. For example, I typed #zap and got #16775, just what I was looking for. (That I would get this was very clear in the UI -

re-engineering overloading and rebindable syntax

Hi devs, I've recently discovered the `overloaded` package, which allows us to do very clever things around overloading in a source plugin. In my over-excitement, I wondered about removing GHC's capability to do overloading and rebindable syntax, leaving those features to be implemented by sour

Re: Multiple instance pragmas

I agree -- I think INCOHERENT essentially subsumes the others. Do you have a counter-example? Richard > On Nov 25, 2019, at 4:28 PM, Brandon Allbery wrote: > > TBH I'd have expected INCOHERENT to cover OVERLAPPABLE, i.e. all bets are off > and you've allowed anything including overlaps. > >

Re: Proposed changes to merge request workflow

I wonder if it would alleviate the concerns to have a ghc-maintainers mailing list. This is distinct from ghc-devs, in that the maintainers have GHC as their day job. It would explicitly invite email from folks struggling to figure out how to contribute. I don't mean to create more mail for Ben

Re: Status of the rich errors proposal

Ben Gamari is, I believe, leading the effort with that proposal. It continues to get attention but has not yet blossomed to something we're ready to debate widely. This is a hard nut to crack, and we'd like to get it right. So I guess all there is to say right now is that the effort is ongoing,

Re: Debugging specialization

Inspection Testing by Joachim Breitner may be of interest: https://arxiv.org/abs/1803.07130 > On Oct 25, 2019, at 5:34 PM, Alexis King wrote: > >> On Oct 25, 2019, at 04:07, Simon Peyton Jones wrote: >> >> | I’ve noticed that Specialise.hs has handful of pprTrace calls sprinkled >> | about,

Re: Handling source locations in HsSyn via TTG

A nice property of Solution D (and I think this is a new observation) is that we could accommodate both located source and unlocated. For example: > data GhcPass (c :: Pass) -- as today > data Pass = MkPass Phase HasLoc > data Phase = Parsed | Renamed | Typechecked > data HasLoc = YesLoc | NoLo

Re: validate-x86_64-darwin failing

> On Oct 13, 2019, at 6:38 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >> Here's one: https://gitlab.haskell.org/rae/ghc/-/jobs/173464 >> <https://gitlab.haskell.org/rae/ghc/-/jobs/173464> I don't know if you >> can get more informat

Re: validate-x86_64-darwin failing

Here's one: https://gitlab.haskell.org/rae/ghc/-/jobs/173464 <https://gitlab.haskell.org/rae/ghc/-/jobs/173464> I don't know if you can get more information... > On Oct 9, 2019, at 1:21 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >> Hi devs, >

T13615 fragile?

Hi devs, https://gitlab.haskell.org/rae/ghc/-/jobs/173504 tells me that T13615 failed -- but only in DEBUG mode. My patch is nowhere near this code. Is this a new fragile test? The number of fragile tests seems to be growing quickly. And once

validate-x86_64-darwin failing

Hi devs, validate-x86_64-darwin seems to be failing. I've restarted it when I came across the failure, but several small patches last night tripped on this. Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/

Re: Proposed changes to merge request workflow

+1 from me. > On Oct 8, 2019, at 7:19 PM, Shayne Fletcher via ghc-devs > wrote: > > All sounds very sensible to me. > > On Tue, Oct 8, 2019 at 2:17 PM Ben Gamari > wrote: > tl;dr. I would like feedback on a few proposed changes [1] to our merge >request wor

<    1   2   3   4   5   6   7   8   9   10   >