Re: D2038: [WIP] TysPrim: Generalize kind of (->)

Richard Eisenberg writes: > I had another thought on my drive home: why do we need to sort out > Constraint v Type for 8.2? I have the patch, and it's essentially all > set. But it weakens equality in a way that's troublesome for D2038 and > introduces heterogeneous axioms,

Re: D2038: [WIP] TysPrim: Generalize kind of (->)

I had another thought on my drive home: why do we need to sort out Constraint v Type for 8.2? I have the patch, and it's essentially all set. But it weakens equality in a way that's troublesome for D2038 and introduces heterogeneous axioms, which are strange, ill-understood beasts. And I don't

Re: Join points revised

Luke Maurer writes: > Revised version of the join points patch is up: > > https://phabricator.haskell.org/D2853 > > Hoping to commit ASAP. Thanks all! > I have a few further review comments that I'm about to submit. Cheers, - Ben signature.asc Description: PGP

Join points revised

Revised version of the join points patch is up: https://phabricator.haskell.org/D2853 Hoping to commit ASAP. Thanks all! - Luke Maurer University of Oregon maur...@cs.uoregon.edu ___ ghc-devs mailing list ghc-devs@haskell.org

Re: D2038: [WIP] TysPrim: Generalize kind of (->)

Richard Eisenberg writes: snip > > I think the Right Answer is to get rid of newtype-classes & fix reify, and > I’m worried that anything short of that will fail catastrophically at some > point. Otherwise, it’s patches on top of patches. > > I don’t think there is

Re: D2038: [WIP] TysPrim: Generalize kind of (->)

> On Jan 31, 2017, at 5:41 PM, Simon Peyton Jones wrote: > > But that can only happen if `(->)` has suitable roles. > What if it doesn’t? The “correct” roles for (->) of the kind you gave is `nominal nominal nominal nominal representational representational`. That is,

RE: D2038: [WIP] TysPrim: Generalize kind of (->)

Replying by email because I'm on a train. Simon Huh. Put otherwise, your point is this. Suppose we have the following kind for `(->)`: (->) :: forall v1 v2 r1 r2. TYPE v1 r1 -> TYPE v2 r2 -> Type To coerce from (C a -> Int) to (a -> Int) we'd have to cough up a coercion `g`: g

Freeze update

Hello everyone, As you likely know, the feature freeze date for the 8.2.1 was yesterday. Unfortunately, it looks like that date may have been a bit optimistic as there are there are still several major patches outstanding that we would like to have for 8.2.1. These are namely, * Join points

Re: Lazy ST vs concurrency

I think Ben's eagerlyBlackhole is what I called noDup. And it is indeed a bit tricky to use correctly. It needs the same sort of care around inlining that unsafePerformIO does. A bit of summary: 1. It's okay to duplicate a runST thunk or to enter it twice, because each copy will have its

RE: Lazy ST vs concurrency

Huh. You are right. That’s horrible. OK, here’s another idea. Provide, applyOnce# :: (a->b) -> a -> b which behaves like applyOnce f x = f x but guarantees that any thunk (applyOnce# f x) will be evaluated with atomic eager black-holing. \(s :: State# s) -> let

Re: Lazy ST vs concurrency

On 31 January 2017 at 09:11, Simon Peyton Jones wrote: > If we could identify exactly the thunks we wanted to be atomic, then yes, > that would be better than a whole-module solution. However I'm not sure > how to do that - doing it on the basis of a free variable with

RE: Lazy ST vs concurrency

If we could identify exactly the thunks we wanted to be atomic, then yes, that would be better than a whole-module solution. However I'm not sure how to do that - doing it on the basis of a free variable with State# type doesn't work if the State# is buried in a data structure or a function

Re: Lazy ST vs concurrency

On 30 January 2017 at 22:56, Simon Peyton Jones wrote: > We don’t want to do this on a per-module basis do we, as > -fatomic-eager-blackholing would suggest. Rather, on per-thunk basis, no? > Which thunks, precisely? I think perhaps *precisely thunks one of whose > free