RE: tcSubsumes

Richard It's clearly wrong as it is, but I suggest you that you make tcSubsumes use captureConstraints rather than pushLevelAndCaptureConstratints. That's what solveEqualities does, after all. Simon | -Original Message- | From: Richard Eisenberg [mailto:r...@cs.brynmawr.edu] | Sent:

RE: valid substitutions for holes

I'm not sure why pure and return are reported now when they weren't before. Characterising that would be helpful. But yes, it's an experimental feature, so I don't think you should hold up the train for it. You should talk to the author. Simon | -Original Message- | From: ghc-devs

RE: GHC build broken

ps this Linux box is way behind gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GHC build broken

Ben: I'm getting this from a clean build on Linux. Any ideas? I'm up to date on master git branch -v data-kind-syntax 4174458178 Add IfacePromotionInfo * master 436b3ef01e Clean up comments about match algorithm a bit. tc-untouchables b737a45391 More simplifications

RE: [ANNOUNCE] GHC 8.2.2 release candidate 2

Thank you for doing this! From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ryan Scott Sent: 03 November 2017 00:19 To: ghc-devs@haskell.org Subject: Re: [ANNOUNCE] GHC 8.2.2 release candidate 2 I built all of Stackage with this RC the other night and didn't observe any

RE: Bringing some observable sharing to GHCi

Do TypeReps need to be cyclic? No – I think David is working on a non-cyclic version Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Marlow Sent: 02 November 2017 10:27 To: David Feuer Cc: Joachim Breitner ;

RE: When does GHC produce unlifted `let` bindings?

Re: let-bindings floating more easily, would a check for `exprIsOkForSpeculation scrut` in theory suffice to float out cases? Yes; but instead we simply turn such cases into lets. Simon From: Sebastian Graf [mailto:sgraf1...@gmail.com] Sent: 02 November 2017 08:33 To: Simon Peyton Jones

RE: GHCi recompilation avoidance UI

I'm lost. * What causes the undesired behaviour in GHC 8.2.1? Is it this? - GHCi wants to load module B with flags F - There is a B.o but the flags differ - So GHCi recompiles B to bytecode * How does (1) help? * Does (2) propose a new command (:load *M vs :load M)? If so, how

RE: Building the docs, again

It is quite confusing that we can be setting the same variable to different values in different places. It would also be quite helpful if we modified the Makefile to say `documentation build target is disabled` or some such, rather then going ahead and building the whole of GHC, only at the

FW: How does GHC's testsuite work?

Forwarding to ghc-devs, a better list for this question. Simon -Original Message- From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Sébastien Hinderer Sent: 30 October 2017 15:18 To: glasgow-haskell-us...@haskell.org Subject: How does GHC's

RE: Types in GADT pattern match

foo b@(Bar :: Foo [a]) = quux b The pattern (p :: ty) checks that the thing being matched has type ‘ty’ and THEN matches ‘p’. You expected it to FIRST match ‘p’, and THEN check that the thing being matched has type ‘ty’. But that’s not the way it works. e.g what about this rats

RE: When does GHC produce unlifted `let` bindings?

See Note [CoreSyn let/app invariant] in CoreSyn. Briefly, you can write let x::Int# = e in … if e is “ok-for-speculation”. See extensive comments in CoreUtils on what that means. You could also use case, but let-bindings “float” more easily than cases, because they are not worried

RE: [commit: ghc] master: Make tagForCon non-linear (faf60e8)

| I considered that, but I'm shy at changing data types. Especially for | caching, because sometimes keeping the data in sync can be difficult. In this case, not so. Just make a smart contructor for DataTyCon and use it. There are very few calls to it anyway! As to the storage cost this is

Family instance consistency

Edward Could you possibly take a look at #14396? It's going to bite us soon, as Alan's Trees That Grow patch lands (see the branch mentioned on the ticket). (In fact, Alan, I don't know how you build that branch ; I can't build it.) Simon ___ ghc-devs

RE: FW: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for @. (31515fa)

g: Use conventional | whitespacing for @. (31515fa) | | Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes: | | > I've received 1500 of these commit messages overnight, and another | arrives every few seconds. Are they likely to stop soon? | > | Oh dear, this looks like an unfor

wip/nfsl-locking

Can anyone switch off this torrent of commit messages for wip/nfs-locking? I'm submerged in junk. I'm about to write a junk-mail rule Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

FW: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for @. (31515fa)

I've received 1500 of these commit messages overnight, and another arrives every few seconds. Are they likely to stop soon? Simon -Original Message- From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of g...@git.haskell.org Sent: 27 October 2017 01:06 To:

RE: Simplify.hs depends on typechecker

I agree. Both of these code paths go through initTcForLookup which is massive overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly a ToDo here to strip off the redundant stuff and do a minimal lookup. Would you like to make a ticket? Simon | -Original Message-

RE: forall in constraint

* Like I say I am DEEPLY suspicious of ForallXImplicitBndrs. I can’t make head or tail of it. Is see in you patch you define type ForallXPat (c :: * -> Constraint) (x :: *) =… What is this? Why do we need it? What goes wrong if we remove it altogether? * Likewise

RE: forall in constraint

I’m lost. Could you give me a bit more context? I’m deeply suspicious about that ForallXImplicitBndrs thing with strange higher kinded parameters. Smells all wrong to me. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 23 October 2017 16:07

RE: haddock specializeInstHead

I don’t know, but my instinct is to stick to the monomorphic version for now, it that’s all you need. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 20 October 2017 18:33 To: ghc-devs@haskell.org Subject: haddock specializeInstHead I am

RE: splitting metavariables

| Actually, I wonder if we can put the check in just one spot: coreView. | Whenever we use coreView, we're about to inspect a type. And we should | never be inspecting a metavariable in this way. Yes, that's right. Maybe that makes a useful distinction between coreView and tcView; the former

RE: More windows

Oddly it's started working. I have no idea why. I'll yell if it breaks again. Simon | -Original Message- | From: Ben Gamari [mailto:b...@well-typed.com] | Sent: 11 October 2017 14:11 | To: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org>; Simon Peyton | Jones

RE: Determine instance method from class method callsite

| lookupInstEnv from the InstEnv module seemed to do it, but it seems to | look up the matching key from a set of instEnv keys and not anything | that contains the instance bindr. Not sure. I couldn't understand this. lookupInstEnv is probably what you want. It returns a ClsInstLookupResult

RE: GHC rewrite rule type-checking failure

For now, I'm trying to determine whether it possible to use the in-scope dictionary variables for constraint solving from a built-in rewrite rule. It would not take deep, pervasive changes. I suggest that you do /not/ call solveWanteds, but instead make a custom constraint solver. The

RE: Invariants about UnivCo?

5) The first suspect turned out to be the culprit: I was using my plugin's by-fiat coercions in the most naive possible way, always simply `EvCast ev (fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new Given unlifted equality witnesses from existing Given unlifted

RE: Invariants about UnivCo?

3) I confirmed that the lack of cobox uniques in the dump output was indeed due to `ppr_co' deferring to `ppr @IfaceType'; it does that (at least) for every coercion with a head of `TyConAppCo'. With a tiny kludgy patch I was able to persist those uniques just for debugging purposes. Would you

RE: More windows

Any ideas anyone? When I restart the build, it gets past the blockage (which seems highly specific). But it’s jolly annoying. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton Jones via ghc-devs Sent: 04 October 2017 17:25 To: Phyx <loneti...@gmail.

RE: In C--: should CmmCall and CmmProc agree on their live registers?

Moritz I have this stuff all paged out. Would you like to give a couple of concrete examples of what you have in mind, with any design alternatives? And illustrate your suggestion about propagation, which I don't yet grok. Thanks Simon | -Original Message- | From: Moritz

RE: Determine instance method from class method callsite

well the HsWrapper might have something much more complicated than a DFunId. It might need to construct the dictionary for Eq [a] from the DFun for Eq [a] and a dictionary for Eq a. it would be easy to resolve the Var of the instance method. I don't know what "the var of the instance method"

RE: In C--: should CmmCall and CmmProc agree on their live registers?

Did you ever get a reply to this? In the output of the codegen, CmmProcs should have no live registers apart from those used to pass args, and the standard ones. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Moritz | Angermann |

RE: Determine instance method from class method callsite

Did you get a reply? I’m not 100% certain of your question, but consider the bar = show for some expression e. In the input to the type type checker the syntax tree for the RHS will be something like HsApp (HsVar “show”) (The “show” isn’t really a string, it’s the Name for

RE: More windows

indows This looks like a file lock issue. Just to double check, but do you have the build folder excluded from the antivirus scanner? On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote: Now in my Windows build, staring

More windows

Now in my Windows build, staring with "sh validate -fast -no-clean" I get [230 of 232] Compiling Distribution.PackageDescription.Parsec ( libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, bootstrapping\Distribution\PackageDescription\Parsec.o ) [231 of 232] Compiling

RE: Windows build broken

on all targets, I'll add msys when I get home. Kind regards, Tamar On Wed, Oct 4, 2017, 11:19 Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote: My Windows build is broken again. With a clean checkout, I get “” Target platform inferred as: x86_

Windows build broken

My Windows build is broken again. With a clean checkout, I get "" Target platform inferred as: x86_64-unknown-mingw32 Unknown OS msys How can I get past this? Full log below. Simon make[1]: Leaving directory '/c/code/HEAD/testsuite' ['libraries/array/', 'libraries/base/',

RE: GHC rewrite rule type-checking failure

The new bit here is that `$dC'` is not found via matching in the LHS, but rather by instance resolution from `k`, which does appear explicitly in the LHS Well this would be something qualitatively new. We don’t that ability in rules; and it’s far from clear to me what it would mean anyway. I

RE: GHC rewrite rule type-checking failure

But synthesising from what? And currently no: there is no type-class dictionary synthesis after the type checker. Not impossible I suppose, but one more fragility: a rule does not fire because some synthesis thing didn’t happen.Maybe give an as-simple-as-poss example of what you have in

RE: Invariants about UnivCo?

Some thoughts * Read Note [Coercion holes] in TyCoRep. * As you’ll see, generally we don’t create value-bindings for (unboxed) coercions of type t1 ~# t2. (yes for boxed ones t1 ~ t2). Reasons in the Note. Exception: for superclasses of Givens we do create(co :: a ~# b) =

RE: The Curious Case of T6084 -or- Register Confusion with LLVM

| One way to make this happen would be for C-- call nodes to carry information | about the calling convention of the target (e.g. how many arguments of each | type the function expects; in the same way identifiers in Core carry their | type). That's be entirely possible for "known" calls,

RE: The Curious Case of T6084 -or- Register Confusion with LLVM

Moritz Talk to Kavon. He was thinking about passing a struct instead of a huge list of registers, and only initialising the live fields of the struct. I don't know whether he ultimately discarded the idea, but it sounded promising. Simon | -Original Message- | From: ghc-devs

RE: Overapproximation of loopbreakers due to unfoldings

INLINE means "Inline what I wrote". So in your example we'd have ===> bindWith [INLINE = ] = bindWith_abc |> co bindWith_abc = If you see a call to bindWith, we will /not/ inline bindWith_abc |> co! We'll inline . That's what the programmer asked for.

RE: A type checker plugin for row types

Nick Good work! You ask some questions about the constraint solver – I hope that the answer from others have helped. If not, do re-ask. My main comment is: what does Core look like? I think your answer is “No change to Core, but there are lots of unsafe coerces littered around”. But even

RE: Perf improvement

Bump it down, maybe... it got /better/! | -Original Message- | From: Ben Gamari [mailto:b...@smart-cactus.org] | Sent: 14 September 2017 16:54 | To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org | Subject: Re: Perf improvement | | Simon Peyton Jones via gh

RE: ./validate --slow results

Wow... 97 unexpected failures is bad. Ben/David/someone else: might you investigate/characterise them? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Bartosz | Nitka | Sent: 14 September 2017 13:57 | To: ghc-devs Devs

Perf improvement

I'm seeing this in validate bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) ExpectedT5837(normal) bytes allocated: 56782344 +/-7% Lower bound T5837(normal) bytes allocated: 52807579 Upper

RE: Performance degradation when factoring out common code

I know that this is not an easy request, but can either of you produce a small example that demonstrates your problem? If so, please open a ticket. I don’t like hearing about people having to use trial and error with INLINE or SPECIALISE pragmas. But I can’t even begin to solve the problem

RE: A newcomer: how to start

Yes, welcome! Do join ghc-devs and watch the fun. There is a learning curve, but as Ara says, everyone is friendly. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ara Adkins Sent: 05 September 2017 13:47 To: Sergey Bykov Cc:

RE: [broken HEAD] In which the strict state monad fails at basic arithmetic

Wow -- Fast work! Do add a test case Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben | Gamari | Sent: 01 September 2017 14:53 | To: Moritz Angermann ; GHC developers | Subject: Re: [broken HEAD] In which

RE: [commit: ghc] master: Adjust test suite stats (a055f24)

d, LLP Original message From: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Date: 8/28/17 4:57 PM (GMT-05:00) To: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> Subject: RE: [commit: ghc] master: Adjust test suite stats (a055f24)

RE: [commit: ghc] master: Adjust test suite stats (a055f24)

David, are you sure we want to accept a more than 5% increase in compile time without investigation? What commit caused these increases? Maybe they are readily squashed? Generally we are trying to improve compiler perf not accept it getting worse! Simon | -Original Message- | From:

RE: Alex install failure

Riedel | <hvrie...@gmail.com>; ghc-devs <ghc-devs@haskell.org> | Subject: RE: Alex install failure | | Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes: | | > | note that you mistyped "lockd" (aka "lock daemon") as "locd" | >

RE: Alex install failure

all failure | | Simon, | | note that you mistyped "lockd" (aka "lock daemon") as "locd" | | also, the output of "rpcinfo -p" would be interesting to know | | On Mon, Aug 28, 2017 at 1:47 PM, Simon Peyton Jones via ghc-devs wrote: | > | Hmm, alright

RE: Alex install failure

| I have implemented this in wip/ghc-pkg-locking. Do you think you could give | this branch a try? If it still fails then we'll have to try to debug things | in-situ. Alas, no go. * I'm on wip/ghc-pkg-locking * I checked that the lock file was removed then I tried this:

RE: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

Hmm I see. I still prefer the concrete form (no intermediate layer). Many constructors use record fields, so you can just omit the ones that aren’t valid. Simon From: Shayan Najd [mailto:sh.n...@gmail.com] Sent: 24 August 2017 15:39 To: Simon Peyton Jones Cc: Alan &

RE: Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs

I’m keen NOT to introduce these layers of indirection. I think they make the code harder to understand. Can you give an example function or two, and what it would look like under the different approaches. (1)-(3) appears to be three different approaches, but I don’t think that’s what you

RE: Docs

sphinx-build --version Sphinx v1.1.3 | -Original Message- | From: Ben Gamari [mailto:b...@smart-cactus.org] | Sent: 22 August 2017 14:55 | To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs | Subject: Re: Docs | | Simon Peyton Jones via ghc-devs <ghc-devs@ha

RE: Stg-lint and bootstrapping (fails?)

Is this with HEAD? I have an up to date HEAD, and with your command line I don't get those warnings. But I do get the OccAnal warnings, so it's not that the warnings are being suppressed. I'm not sure how to reproduce. Does this happen on anything smaller? Eg. on a testsuite program (you'll

Docs

Ben et al I’m getting this on Linux when making documentation. I have not modified any of this documentation. Any ideas? Simon reading sources... [ 97%] what_glasgow_exts_does reading sources... [100%] win32-dlls reading sources... [ 97%] what_glasgow_exts_does reading sources... [100%]

RE: Stg-lint and bootstrapping (fails?)

| Oh dear, then I've really misunderstood the intent of this warning. I've | been noticing these during the GHC build for quite some time now. Really? After stumbling on #14142, I removed -dno-debug-output from mk/flavours/validate.mk and re-validated. Not a single occurrence of | > |

RE: Alex install failure

rom: Ben Gamari [mailto:b...@smart-cactus.org] | > | Sent: 18 August 2017 13:05 | > | To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs | d...@haskell.org> | > | Subject: Re: Alex install failure | > | | > | Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org

RE: Alex install failure

3 AM, Simon Peyton Jones via ghc-devs wrote: | > | Hmm. Here's a shot in the dark: is home home directory mounted via | > | NFS by any chance? | > | > Direct hit! (for the shot in the dark). Yes it's NFS mounted I think. | So what? | | Then you're another victim of | | https://ghc.has

RE: Where to discuss the linear types extension of GHC?

But it could also be never, if the committee rejects the proposal... Don’t let that put you off. The more numerous and compelling the applications, the more likely it is that the committee will accept it! It’s a Big Feature, so the bar is high. But if there is a diverse bunch of actual

RE: Alex install failure

| To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs | Subject: Re: Alex install failure | | Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes: | | > Friends | > I'm trying to update my installation of alex, on Unix (Ubuntu). But I | > get the dump below It's com

RE: Alex install failure

...@gmail.com] | Sent: 18 August 2017 11:59 | To: Simon Peyton Jones <simo...@microsoft.com> | Subject: Re: Alex install failure | | Try removing | | /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock | | | | On Fri, Aug 18, 2017 at 12:25 PM, Simon Peyton Jones via ghc-devs

RE: Stg-lint and bootstrapping (fails?)

| WARNING: file compiler/simplCore/OccurAnal.hs, line 2695 | OccurAnal failed to rediscover join point(s): [go58_akKa] That shouldn't happen! If you can make a repro case, please open a ticket. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On

Alex install failure

Friends I'm trying to update my installation of alex, on Unix (Ubuntu). But I get the dump below It's complaining about a lock file being an invalid argument (see highlight below). If I manually remove the file I get past that, it successfully installs tf-random, but the same thing happens on

RE: Occurrence info on binders and STG

Can you be more specific? I don’t think occurrence info is used at all in STG. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor | Greif | Sent: 01 August 2017 16:02 | To: ghc-devs | Subject: Occurrence info on

RE: Restructuring hsSyn

I don’t object. (They’d be orphan instances, so the interface file will always be loaded; but that’s probably ok. From: Shayan Najd [mailto:sh.n...@gmail.com] Sent: 02 August 2017 11:50 To: ghc-devs@haskell.org Cc: Simon Peyton Jones ; Alan & Kim Zimmerman

RE: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy (6a50466)

Joachim Aha! I think my comment on Phab is redundant. You are simply avoiding name capture, which is obviously right; you are not restricting the applicability of the transformation. Needless to say, a Note would help in due course. S | -Original Message- | From: ghc-commits

RE: dataToTag# documentation

Based on memory rather that investigation: - yes it works on any data type - The reason that the primop dataToTag# is dangerous is that it does not evaluate its argument; it relies on the wrapper getTag to do so.Caveat emptor! It would be good to document this. Simon | -Original

RE: GHC 8.2 generated code faster than 8.0 but slower than 7.10

Thanks. Could you open a Trac ticket, and explain carefully how to reproduce your results? Surely 8.4 should be faster than 7.10! Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Harendra Kumar Sent: 01 August 2017 10:46 To: ghc-devs@haskell.org Subject: GHC 8.2

RE: Operating on HsSyn

Am I far off? I don’t think you are far off. All I’m after is the debug-printer use-case: I want to be able to see the contents of the tree, including the PostRn annotations. I don’t care about round-tripping it. Simon From: Shayan Najd [mailto:sh.n...@gmail.com] Sent: 28 July 2017 15:32 To:

RE: Operating on HsSyn

I have been under the impression that we don't even want to print those. On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see what the renamer has done? Simon From: Shayan Najd [mailto:sh.n...@gmail.com] Sent: 28 July 2017 12:20 To: Simon Peyton Jones

Operating on HsSyn

Devs, Shayan is working away on "Trees that grow"... do keep it on your radar: To: ghc-devs Sent: 25 May 2017 23:49 Do take a look at this: * We propose to re-engineer HsSyn itself. This will touch a lot of code. * But it's very neat, and will bring big long-term advantages

RE: [commit: ghc] master: Improve error messages around kind mismatches. (8e15e3d)

| typecheck/should_fail/T7368) Solution: track the provenance of | Derived constraints and refuse to float out a constraint that has | an insoluble Derived. For the record, that's not the solution that the patch implements. Instead we just don’t float heterogeneous equalities. I

RE: D3754: Refactor uo_thing

Richard I'm on a train, so can't look at the detail. But the following thought occurs to me. uo_thing is a Maybe SDoc attached to a constraint. But a constraint also has a stack of [ErrCtxt], captured in the CtLoc. That's what produces the "In the declaration for ..." stuff. Idea:

RE: Repeated computations under a lambda

I opened a ticket and replied: https://ghc.haskell.org/trac/ghc/ticket/13996#comment:1 Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 19 July 2017 01:01 To: David Feuer Cc: ghc-devs@haskell.org Subject: Re: Repeated

RE: Proposed: Language.Haskell.TH.Internal

OK with me, provided we document the thinking so that users understand the architecture. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard | Eisenberg | Sent: 18 July 2017 13:27 | To: GHC developers | Cc: Ryan

Simon's (lack of) input

Friends My GHC inbox has grown to alarming proportions. I try to keep abreast of tickets where I think I have something substantial contribute, and generally succeed, but I've been failing badly in the last few weeks because of a storm of other commitments. I'll get back to it, but probably

RE: Compilation time

Thanks Gael. As you may know, we’ve focused a lot on compile time in the last year or so, and 8.4 is a lot faster. I think there are still plenty of bad cases, but things are better. Our compile-time perf page is here: https://ghc.haskell.org/trac/ghc/wiki/Performance/Compiler It links to a

RE: Which stable GHC release is expected to have support for linear types?

Wolfgang It'd be very interesting to know more about your use-case. Why do you want linear types? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Wolfgang Jeltsch | Sent: 30 June 2017 14:49 | To: ghc-devs@haskell.org | Subject:

RE: Which stable GHC release is expected to have support for linear types?

And, just to be clear, while I think the design is coming along nicely, we have not yet made a clear proposal to the ghc-devs community, via the ghc-proposals mechanism, for a change to GHC. Until we have an adopted propsoal we can't say "it'll be in GHC by date X". Simon | -Original

RE: Windows broken

ne of the above give a clue, you could try ./configure --enable-distro-toolchain, this will have it skip the bundled GCC And use any installed by msys2. If this work then try rm’ing the GHC-tarballs folder and the inplace/mingw folder and try again With –enable-tarballs-autodownloads. Tamar. From: Si

RE: Windows broken

mingw folder and try again With –enable-tarballs-autodownloads. Tamar. From: Simon Peyton Jones via ghc-devs<mailto:ghc-devs@haskell.org> Sent: Thursday, June 29, 2017 00:35 To: ghc-devs<mailto:ghc-devs@haskell.org> Subject: Windows broken Help please! Suddenly my Windows build has stop

Windows broken

Help please! Suddenly my Windows build has stopped working. See below. What should I do? I'm totally stuck. This has never happened before. I get this: GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc checking build system type... x86_64-pc-msys checking host system type...

Thank you

Ryan I wanted to thank you for all the work you are putting into GHC at the moment. * You often produce nice small repro cases from other people's bug reports * you often bisect to the patch caused the bug; * your analysis is usually spot on; * you are actively maintaining the

hoopl dependency

Devs, Matko (an intern here at MSR) says Matko Bosnjak 19:02: Hi Simon, There's a 'bug' in some of the latest commits of ghc on git. When running ./build I get: Error: libraries/hoopl/LICENSE doesn't exist. Maybe you haven't done 'git submodule update --init'? at ./boot line 112, line 54.

#13804

Ben I've just pushed a fix to Trac #13804. It may belong on the 8.2 branch too because it fixes a regression wrt 8.0. I can't test on my Unix box, because I'm away from it for a few days, but I've validated on windows. Can you just check it's ok, and fix up or revert if not? Thanks SImon

GHC's module hierarchy

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the

RE: Removing Hoopl dependency?

Speaking of which, what policies are there on bringing in new dependencies to GHC, both compile-time and run-time (e.g. possible SMT solver support)? We don’t have a formal policy, but we are generally reluctant to take on new dependencies. For SMT solvers, Iavor is using one via a

RE: Removing Hoopl dependency?

Interesting! Maybe there are a couple of different alternatives: A. A rewrite of Hoopl, with all the same basic ideas and data structures, but with a better API (I’m not sure exactly in what way, but Michael has some idea, as does Sophie), and a more efficient implementation. B. A

RE: 8.2.1-rc2 upgrade report

Great. Could you put all this into a Trac ticket? Thanks! Simon From: Alberto Valverde [mailto:albe...@toscat.net] Sent: 08 June 2017 13:57 To: Simon Peyton Jones Cc: GHC users Subject: Re: 8.2.1-rc2 upgrade report Hi Simon, Thanks

RE: Removing Hoopl dependency?

Maybe this is the core of our disagreement - why is it a good idea to have Hoopl as a separate package in the first place? One reason only: because it makes Hoopl usable by compilers other than GHC. And, dually, efforts by others to improve Hoopl will benefit GHC. If I proposed extracting

RE: Removing Hoopl dependency?

Michael Sorry to be slow. Note that what I’m actually advocating is to *finish* forking Hoopl. The fork really started in ~2012 when the “new Cmm backend” was being finished. Yes, I know. But what I’m suggesting is to revisit the reasons for that fork, and re-join if possible. Eg if Hoopl is

RE: Trees that Grow in the hsSyn AST

| just wondering what led to the decision to start with HsSyn. Are you | suggesting that Core wouldn't benefit from these ideas? I surely don't Core, unlike HsSyn, is heavily optimised and transformed. It's hard to see how the transformations could soundly maintain arbitrary auxiliary

RE: Removing Hoopl dependency?

Is there really a compelling case for forking Hoopl? I was talking to Kavon last week about doing exactly the opposite: using Hoopl more wholeheartedly! Before going ahead with this, let’s remember the downsides ·If we fork Hoopl, improvements in one place will not be seen in the

RE: [commit: ghc] master: Fix test output after 'Some tidying up of type pretty-printing' (09d5c99)

Sorry about this. I carefully fixed all these and validated...thanks for fixing Simon | -Original Message- | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of | g...@git.haskell.org | Sent: 27 May 2017 15:45 | To: ghc-comm...@haskell.org | Subject: [commit: ghc]

RE: HsParTy

I can try to strip then all out and see what happens. That’d be good! With a Note to explain why… We still need ctxt_prec, I think, to pass to the ordinary type pretty-printer, when we have HsCoreTy. Simon From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: 26 May 2017 12:14 To:

RE: Trees that Grow in the hsSyn AST

fferent variable representation (unbound, bound, abt, etc)? David Feuer Well-Typed, LLP Original message ---- From: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> Date: 5/25/17 6:48 PM (GMT-05:00) To: Alan & Kim Zimmerman &l

<    2   3   4   5   6   7   8   9   10   >