Re: Multiple GHC sessions

On 18 January 2016 at 11:18, Alan & Kim Zimmerman wrote: > From a tool writer perspective I would be happy to have GHC/Linker > sessions be completely separate from each other. But I guess in > practical terms a shared address space needs to be managed, making > this

equality relations: user-facing pretty-printing question

Hi devs, I've recently made a design decision for GHC 8.0 that I may wish to revisit, and I'd love some feedback. GHC 7.x has but one user-visible type equality relation, ~. The constraint (ty1 ~ ty2) is well-kinded only when ty1 and ty2 have the same kinds. And the solver works in terms of

RE: Multiple GHC sessions

Simon Peyton Jones writes: > I don't think the state-hack tail should wag the dog here. The nub of > the problem in practice is the shared linker state isn't it? > I'm not sure; it's not clear to me what would break if the linker were used by more than one session at a

RE: Multiple GHC sessions

I don't think the state-hack tail should wag the dog here. The nub of the problem in practice is the shared linker state isn't it? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben | Gamari | Sent: 17 January 2016 19:55 | To: Alan &

Re: Phab failing to apply patches

Just to chime in here: I agree with Janek that the current requirement that Phab always cherry-picks changes against master is annoying. I have a limited amount of computing power available locally, and it's much easier to push to Phab than to slow down my primary dev machine for 2+ hours.

Re: Phab failing to apply patches

On Mon, Jan 18, 2016 at 5:49 PM, Jan Stolarek wrote: > > If you are working from an old base commit, either rebase your patch > before > > submitting to Phabricator (painful? you will have to do it before pushing > > anyway, might as well do it now), or ignore the

Re: Phab failing to apply patches

> * you validate locally (in a different build directory, so you can keep > using build flavour = devel2 in your development directory) > * fork the ghc github repository, push your branch there, and let Travis > validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis > * ask

Re: equality relations: user-facing pretty-printing question

In my ideal world, GHC would remember as much as what the user wrote as possible in printing error messages. So if the user writes: f :: Int ~ Char => ... Then GHC would remember that the context was written with a single tilde, and print out Int ~ Char in the error message explicitly

Re: ghci and unfoldings?

That's the flag I would expect. It doesn't seem to help or hinder availability of unfoldings in GHCi. Do you think it should? And Happy Birthday, Simon! Warmly, - Conal On Monday, January 18, 2016, Simon Peyton Jones wrote: > Or -fexpose-all-unfoldings? > > Simon > > |

Re: equality relations: user-facing pretty-printing question

Hello, What's the difference between `~~` and `~#` (I assume `~#` is heterogeneous)? As for the rest, as far as I understand, `~` is a strict subset of `~~` in the sense that: 1. if `a ~ b`, then `a ~~ b` 2. if `not (a ~ b)`, then `not (a ~~ b)` 3. if `a ~ b` is a kind error (i.e., the

Re: equality relations: user-facing pretty-printing question

I like that idea. Do others? Yes, agreed about the difference between ~ and ~~. ~# is unlifted, and is now the type that the solver works on. ~~ is lifted. That's the only difference. But the fact that ~~ is lifted is what allows you to put it in a constraint, because all constraints are

Re: equality relations: user-facing pretty-printing question

If ~# is hidden from the user, I think it's reasonable to hide it as an implementation detail. The idea Iavor had sounds good, but we can get (potentially) confusing error messages when writing `Int ~~ Char => ...` -- the smart pretty printer would print `Int ~ Char`. Might get a bit messy. On

Re: equality relations: user-facing pretty-printing question

That sounds like a great idea to me. Ryan S. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: kind of type equalities (was: equality relations: user-facing pretty-printing question)

And lifted ones can exist at runtime, via deferred type errors. With deferred type errors, a lifted equality might be a thunk that evaluates to a type error. I also think that "because Core needs it" is a satisfying answer. That's why we have coercions. If we didn't care about type-checking

Re: ghci and unfoldings?

The minimum flags I've found to get ghci to provide unfoldings are -O and -object-code. And it appears that both flags need to be present the first time I load a module into GHCi. (I'm putting the flags in an OPTIONS_GHC pragma.) On Mon, Jan 18, 2016 at 9:46 AM, Conal Elliott

Re: kind of type equalities (was: equality relations: user-facing pretty-printing question)

On Mon, Jan 18, 2016, at 10:26, Richard Eisenberg wrote: > And lifted ones can exist at runtime, via deferred type errors. With > deferred type errors, a lifted equality might be a thunk that evaluates > to a type error. Ah, fair point. > I also think that "because Core needs it" is a

Re: Multiple GHC sessions

>From a tool writer perspective I would be happy to have GHC/Linker sessions be completely separate from each other. But I guess in practical terms a shared address space needs to be managed, making this impossible. The external interpreter for GHCI effectively solves the actual loading problem,

Re: Phab failing to apply patches

On Sun, Jan 17, 2016 at 4:24 PM, Jan Stolarek wrote: > Can we somehow force Phab to apply a patch against a base commit from > which the patch was created? > I don't know about "somehow", maybe Austin knows a way. The current default should not be changed though, in my

Re: Phab failing to apply patches

> If you are working from an old base commit, either rebase your patch before > submitting to Phabricator (painful? you will have to do it before pushing > anyway, might as well do it now), or ignore the Harbormaster validate > result. I am typically working on some non-trivial features (ie.

Re: Phab failing to apply patches

On Mon, Jan 18, 2016 at 12:09 PM, Thomas Miedema wrote: > * you validate locally (in a different build directory, so you can keep > using build flavour = devel2 in your development directory) > * fork the ghc github repository, push your branch there, and let Travis >

Birthday greetings

Dear GHC devs (all 600+ of you), It’s my birthday (well it was a few minutes ago, but I became distracted by #11379). I am 58. GHC is alive and well and, happily, so am I. However, of late I have found that my GHC inbox, which I used to be able to keep under control, just grows and grows.

Re: Birthday greetings

Dear Simon! Happy Birthday!!! :) Thank you so much for all the incredible work that you have done and the guidance that you have provided over the many years. I personally have profited enormously from your kindness, and I am very grateful for that. In addition, your unwavering enthusiasm for

Re: Birthday greetings

Happy Birthday! Haskell is all the better for your work and direction and we've all benefited thereby. Your work has made computing more enjoyable for many :) On Mon, Jan 18, 2016 at 6:22 PM, Simon Peyton Jones wrote: > Dear GHC devs (all 600+ of you), > > It’s my

How to build profiled stage1?

I'm trying to debug my stage1 compiler and as a last resort I'm trying to build stage1 compiler using `-prof -fprof-auto` to be able to do `+RTS -xc -RTS` during the stage2 build. I tried couple of things but they all failed in different ways. As far as I understand, both SRC_HC_OPTS and

Re: equality relations: user-facing pretty-printing question

It is better, but you still might write ~~ and see an error message with ~, right? On Mon, Jan 18, 2016 at 9:55 AM, Richard Eisenberg wrote: > I like that idea. Do others? > > Yes, agreed about the difference between ~ and ~~. > > ~# is unlifted, and is now the type that the