Re: A GHC Library

> How do you suggest getting around copyright issues? LIke Eric said - by posting pre-prints. I think this should be legal. Note also these two clauses in the ACM Copyright Agreement: 1. "Copyright to the Work (...) is hereby transferred to the ACM (...) effective as of the date of this

Re: Plugins: Accessing unexported bindings

The problem, as I recall, is that GHC does an initial bit of dead-code elimination in the desugarer, before the plugins have a chance to run. (I believe this is part of simpleOptPgm, but may be mistaken) I'm not sure why this is done in the desugarer, it seems to be out of place there. On Mon,

Re: How do I use CallStack?

And sorry if my tone on those emails was a bit snarky. It was late... though snarkiness at any hour is unwelcome. :) I understand the concerns about the Show instance, though I have no opinion about the name of the pretty-printer. My only request is that the pretty-print function is easily

RE: Allow ambiguous types (with warning) by default

| OK, fine. Is there a way to make it an error, but keep checking the | rest of the module? My goal is *get both messages if possible*, within | a module. I'm not tied to any particular mechanism of doing so. Yes it'd be possible. A bit fiddly, but certainly possible. Of course, doing so can

Haddock for GHC 8.0

tl;dr: Help needed to bring Haddock up-to-date for the GHC 8.0 release. Hello everyone, As you likely know, the GHC 8.0 release cycle is quickly drawing to a close. One of the tasks that remains outstanding is porting the patches on Haddock's `ghc-head` branch to `master`. This task is bound

Kind equalities

Richard What’s your ETA on the kind-equality stuff? We wondered in today’s call. We want to make an RC next week. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How do I use CallStack?

On Mon, Dec 7, 2015, at 06:15, Richard Eisenberg wrote: > And sorry if my tone on those emails was a bit snarky. It was late... > though snarkiness at any hour is unwelcome. :) > > I understand the concerns about the Show instance, though I have no > opinion about the name of the

Re: [ANNOUNCE] 7.10.3 release candidate 3

On 2 December 2015 at 01:54, Jens Petersen wrote: > On 29 November 2015 at 23:54, Ben Gamari wrote: >> On that note, 7.10.3 is coming. At the moment I am blocked on getting a >> Cabal release tagged but hopefully this will happen Real Soon Now(TM). > >

RE: Plugins: Accessing unexported bindings

Simon Peyton Jones writes: > Plugins get to edit the entire core-to-core pipeline! There is no magic. At > least I don’t think so > > file:///Z:/tmp/users_guide/compiler-plugins.html > Or for those of us who aren't using Simon's desktop...

Re: question about coercions between primitive types in STG level

Note that int2Float# converts an Int# to the Float# with the same numeric value (e.g. 72 -> 72.0), not the one with the same bit representation (which doesn't really make sense anyways since Int# and Float# may be different sizes). So I think it's not what you want. At least on x86_64, it's

Re: question about coercions between primitive types in STG level

Thanks Simon, primops worked fine, but not I'm getting assembler errors(even though -dcore-lint, -dstg-lint and -dcmm-lint are all passing). The error is caused by this STG expression: case (#,#) [ds_gX8 ds_gX9] of _ { (#,#) tag_gWR ubx_gWS -> case tag_gWR of tag_gWR {

RE: Plugins: Accessing unexported bindings

It would not be hard to stop the desugarer dropping dead bindings, if that was helpful. S | -Original Message- | From: Eric Seidel [mailto:e...@seidel.io] | Sent: 07 December 2015 15:44 | To: Simon Peyton Jones | Cc: Levent Erkok ;

Re: How do I use CallStack?

Eric Seidel writes: > Hi Richard, > > Sorry for all of the confusion, it seems the docs do indeed need some > love! > > On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote: >> That looks like exactly what I want. Thanks. >> >> There remain two mysteries: >> - I thought that

RE: Plugins: Accessing unexported bindings

In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being. “Exported” in this context only means “keep alive”. It does not mean exported in the Haskell

Re: How do I use CallStack?

If you're debugging GHC, I've recently added pprSTrace :: (?location :: CallStack) => SDoc -> a -> a in Outputable. It's been a great help for me in understanding where the calls were coming from. You can just use it without importing anything extra, and when you want more context you just add

Re: Phab out of memory

Richard Eisenberg writes: > On Dec 5, 2015, at 9:01 AM, Ben Gamari wrote: > >> Richard Eisenberg writes: >> >>> I just tried to update D808, but the following happened. Any ideas? >>> >> I'm afraid I don't know what to say here.

RE: Plugins: Accessing unexported bindings

If it's "dead" in this sense, it's already removed from ModGuts, no? Yes, if it’s dead it’s gone. That’s not too surprising, is it? So you need a way to keep it alive. Maybe we need a pragma for that. Or how would you like to signal it in the source code? Simon From: Levent Erkok

RE: question about coercions between primitive types in STG level

If memory serves, there are primops for converting between unboxed values of different widths. Certainly converting between a float and a non-float will require an instruction on some architectures, since they use different register sets. Re (2) I have no idea. You'll need to get more

Re: How do I use CallStack?

On 07/12/15 11:59, Ben Gamari wrote: >> If the name "showCallStack" suggests the compiler-derived output, we >> could change it to something like "prettyCallStack" or >> "formatCallStack", I don't have a strong opinion there. > > I have also struggled with these sorts of naming decisions. The >

Re: Plugins: Accessing unexported bindings

Thanks Simon.. But I remain utterly confused. As a "plugin" author, how do I get my hands on the Id associated with a top-level binder? If it's "dead" in this sense, it's already removed from ModGuts, no? That is, by the time GHC runs my plugin, the Id has already disappeared for me to mark it

Re: question about coercions between primitive types in STG level

Simon's right, you need an explicit conversion, and unfortunately those conversions don't currently exist. You would have to add them to the MachOp type, and implement them in each of the native code generators. The good news is that if you did this, we could implement cheap conversions

Re: Plugins: Accessing unexported bindings

Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive. Is that something one of the core-developers can implement? Happy to open a ticket if that helps. > On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones wrote: > > If it's "dead"

RE: Plugins: Accessing unexported bindings

Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC should keep it alive. Really? It might be something like “don’t give warnings for this binding” or “don’t inline me” or something. To say *any* annotation seems a bit brutal doesn’t it?Mind you I don’t have a

Re: Plugins: Accessing unexported bindings

That's a good point; keeping all annotated bindings alive seems to be an overkill.. Regarding implementing "pass at the start." I'm not sure if plugin authors have any freedom as to decide when their plugin actually runs. It seems GHC magically determines the order and runs them. Can you point

RE: Plugins: Accessing unexported bindings

Plugins get to edit the entire core-to-core pipeline! There is no magic. At least I don’t think so file:///Z:/tmp/users_guide/compiler-plugins.html S From: Levent Erkok [mailto:erk...@gmail.com] Sent: 07 December 2015 13:11 To: Simon Peyton Jones Cc: Eric Seidel

Re: A GHC Library

I think a lot of conferences allow authors to host pre-prints elsewhere, like arXiv. We could ask the authors of the relevant papers to make the submission and then update the links on the Reading List. (Perhaps arXiv even has some sort of collection feature?) But you're right that we probably

Re: How do I use CallStack?

> > As quite a separate point from above, I may have found a bug: I put a > > (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then > > put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained > > about a redundant constraint on rewriteEqEvidence, and indeed its

Re: A GHC Library

I know this is a bit old, but I just had a thought that perhaps we could archive GHC papers on arxiv.org? This should be permanent and with a bit of effort we can get around copyright issues (I think). Surprisingly little Haskell research can be found on arXiv and perhaps it is time we

Re: How do I use CallStack?

On Dec 7, 2015, at 2:23 PM, Eric Seidel wrote: > After staring at your bug confusedly for a few minutes, wondering why I > couldn't simplify it, I realized that the actual warning I was getting > was in *mkTcTransCo*, not rewriteEqEvidence. mkTcTransCo does not in > fact use a

Re: How do I use CallStack?

Oh I forgot to mention that I was testing on my local branch which fixes precisely this kind of bug when the CallStack is used inside a let-binder, which is what happens in rewriteEqEvidence. So it looks like my patch takes care of this issue. Thanks for the report! Sent from my iPhone > On

Re: [ANNOUNCE] 7.10.3 release candidate 3

Andrés Sicard-Ramírez writes: > On 2 December 2015 at 01:54, Jens Petersen wrote: >> On 29 November 2015 at 23:54, Ben Gamari wrote: >>> On that note, 7.10.3 is coming. At the moment I am blocked on getting a >>> Cabal release

Re: Kind equalities

I'm on track for that. Did a bunch of performance-related debugging over the weekend, and I can observe nice improvements. Just checking those fixes now. If the results are acceptable, I have to double-check testsuite wibbles and then I'll rebase, validate, and push. Richard On Dec 7, 2015,

RE: A GHC Library

Fine with me! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan | Stolarek | Sent: 07 December 2015 19:23 | To: ghc-devs@haskell.org | Subject: Re: A GHC Library | | I know this is a bit old, but I just had a thought that perhaps we could

Re: Plugins: Accessing unexported bindings

Thanks for the explanation, Simon. I think Eric is spot on. Looking at some of the "ghc -v3" output, it appears GHC always runs the following passes before any plugins are run: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Desugar: Just judging by the name, it could either be the

-XStrict: Why some binders are not made strict?

Let's say I have this code: zip :: [a] -> [b] -> [(a, b)] zip [] [] = [] zip (x : xs) (y : ys) = (x, y) : zip xs ys With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering about the motivation behind this, I found this interesting. I always thought -XStrict gives me

Re: -XStrict: Why some binders are not made strict?

> Aren't those already guaranteed to be strict because of pattern matching? Try > it again with irrefutable patterns. But pattern matching only forces the evaluation up to the pattern that is matched. We need another pattern matching(or seq etc.) on x, y, xs and ys here. If you look at the

Re: -XStrict: Why some binders are not made strict?

On Mon, Dec 7, 2015 at 8:40 PM, Ömer Sinan Ağacan wrote: > With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering > about > the motivation behind this, I found this interesting. I always thought > -XStrict > gives me this guarantee: If I'm using an

Re: A GHC Library

How do you suggest getting around copyright issues? I think that's a real barrier to this (good) idea. Richard On Dec 7, 2015, at 2:23 PM, Jan Stolarek wrote: > I know this is a bit old, but I just had a thought that perhaps we could > archive GHC papers on >