Re: [Haskell-cafe] [ANNOUNCE] GHC 9.4.4 is now available

Excellent! On Sat, Dec 24, 2022, 10:29 PM Ben Gamari wrote: > David Feuer writes: > > > Does this release include the fix for #22549 (infinite loops for some > > undecidable instances)? > > > Yes, it includes a backport of !

Re: [ANNOUNCE] GHC 9.4.4 is now available

Does this release include the fix for #22549 (infinite loops for some undecidable instances)? On Sat, Dec 24, 2022, 5:36 PM Ben Gamari wrote: > The GHC developers are happy to announce the availability of GHC 9.4.4. > Binary > distributions, source distributions, and documentation are available

Re: Run-time absence info

o apply (\ _ -> a) to b. Suppose we define `fmap` for plain arrays (I know; probably not the best example), and let <$ take its default implementation: (<$) a = fmap (const a) If we calculate x <$ arr, that will fill an array with thunks, each of them retaining an element of the

Absence info at run-time

Suppose `f` doesn't use its first argument. When forming the thunk (or partial application) `f a`, we don't need to record `a`. What if instead of arity, we store a bitmap used/absent arguments, terminated by a 1 bit? Could we then get rid of "stupid thunks" like `(const a) b`?

Not all splices are the same

I've been a bit upset by the challenges Template Haskell poses for type inference. For example, (3 :: Int) == $$(...) may typecheck when $$(...) == (3 :: Int) does not. I don't imagine this problem can be solved in general, but I'm rather curious whether it might be possible to solve for

Re: [Haskell] [ANNOUNCE] GHC 9.0.2 released

There's no such directory in the Hackage or GitHub source. I guess it must have crept in on the GHC side? On Sun, Jan 23, 2022, 4:13 AM Jens Petersen wrote: > On Sun, 23 Jan 2022 at 15:40, David Feuer wrote: > >> Could you explain what you mean about the containers source not bei

Re: [Haskell] [ANNOUNCE] GHC 9.0.2 released

Could you explain what you mean about the containers source not being "clean"? On Sun, Jan 23, 2022, 2:31 AM Jens Petersen wrote: > First of all a big thank you and congratulations on the highly anticipated > 9.0.2 release. > > I have been putting off this mail for a while: > I actually built

Re: [Haskell-cafe] Bundle patterns with type aliases

p > -1 is making up 1-2 toy examples and explaining what and why you want it on > a ghc ticket! > > On Wed, Sep 8, 2021 at 1:25 PM David Feuer wrote: > >> I would like that, along with the ability to bundle patterns with classes. >> >> On Wed, Sep 8, 2021, 1:13 P

Re: [Haskell-cafe] Bundle patterns with type aliases

ng what and why you want it on > a ghc ticket! > > On Wed, Sep 8, 2021 at 1:25 PM David Feuer wrote: > >> I would like that, along with the ability to bundle patterns with classes. >> >> On Wed, Sep 8, 2021, 1:13 PM Keith wrote: >> >>> Is there currently a w

Re: [ANNOUNCE] GHC 9.2.1-rc1 now available

I mean GHC.Tuple, of course. On Sun, Aug 22, 2021, 8:14 PM David Feuer wrote: > One more question: is Solo exported from Data.Tuple yet, or do we still > have to depend on ghc-prim and import it from GHC.Magic? It would be really > nice to have that fixed by release, and it'

Re: [ANNOUNCE] GHC 9.2.1-rc1 now available

One more question: is Solo exported from Data.Tuple yet, or do we still have to depend on ghc-prim and import it from GHC.Magic? It would be really nice to have that fixed by release, and it's so tiny. On Sun, Aug 22, 2021, 6:01 PM Ben Gamari wrote: > > Hi all, > > The GHC developers are very

Re: [ANNOUNCE] GHC 9.2.1-rc1 now available

Have array and reference types and primos been updated to be BoxedRep-polymorphic, or is it still just expensive scaffolding? On Sun, Aug 22, 2021, 6:01 PM Ben Gamari wrote: > > Hi all, > > The GHC developers are very happy to announce the availability of the > release cadidate of the 9.2.1

Re: Interruptible foreign calls, part 2

Whoops, I meant `interruptible yield`. Sorry for the confusion. On Mon, Jan 4, 2021, 1:22 AM David Feuer wrote: > Another issue is that (as the recently expanded documentation shows), > an `interruptible` foreign call is not actually an "interruptible > operation"

Interruptible foreign calls, part 2

Another issue is that (as the recently expanded documentation shows), an `interruptible` foreign call is not actually an "interruptible operation" in the sense used in Control.Exception. To make it so, the caller has to manually call `allowInterrupt`. Or, in the single-threaded runtime, has to

Interruptible foreign calls and uninterruptibleMask

As I understand it, `interruptible` foreign calls aren't affected by the masking state at all. It seems to me that they really should respect `uninterruptibleMask`. In particular, within the scope of `uninterruptibleMask`, if an exception arrives and successfully interrupts the foreign call, then

Re: Fwd: Restricted sums in BoxedRep

t some of the benefits that I wanted in this direction were > already there with pointer tagging. > > On Thu, Oct 15, 2020 at 12:59 PM David Feuer > wrote: > >> Yes, that's something quite different. We'd need a whole different heap >> object type for such MVars and TVars.

Re: Fwd: Restricted sums in BoxedRep

gs that aren’t pointery, and could be represented by a > tvar paired with a mutable byte array or mvar with mutable byte array, but > which we’d want considered as a single heap object from the rts/gc > perspective. > > On Thu, Oct 15, 2020 at 11:58 AM David Feuer > wrote: > >>

Re: Fwd: Restricted sums in BoxedRep

Sorry, unlifted, not unboxed... On Thu, Oct 15, 2020, 11:57 AM David Feuer wrote: > Putting unboxed things in TVar, MVar, etc., is part of Andrew Martin's > accepted BoxedRep proposal. > > On Thu, Oct 15, 2020, 11:44 AM Carter Schonwald < > carter.schonw...@gmail.com> wrote

Re: Fwd: Restricted sums in BoxedRep

tions would be: >> >> * How big is the benefit in practice? How many use cases are there? >> * How bad are the costs? (Runtime overhead, rts complexity, ...) >> >> The details of how this would be exposed to a user would are important. >> But if the costs are to

Fwd: Restricted sums in BoxedRep

in BoxedRep To: David Feuer You'll have to forward this to the ghc-devs list to share it with others since I'm not currently subscribed to it, but I've had this same thought before. It is discussed at https://github.com/andrewthad/impure-containers/issues/12. Here's the relevant excerpt: > Relate

Re: Restricted sums in BoxedRep

Yes, I think you're getting the gist. Pattern matching with one or two nulls is just an equality test or three. In practice, we'd want a fixed number of evenly spaced nulls, allowing jump table techniques to be used when there are more cases. We'd presumably have a hard limit for the number of

Re: Restricted sums in BoxedRep

ng that combining such a `Nullable# a` > with another data structure may very well require an additional boxing, > which is what, I believe, you were trying to avoid. > > /Arnaud > > On Tue, Oct 13, 2020 at 11:47 PM David Feuer > wrote: > >> Null pointers are widely known to

Restricted sums in BoxedRep

Null pointers are widely known to be a lousy language feature in general, but there are certain situations where they're *really* useful for compact representation. For example, we define newtype TMVar a = TMVar (TVar (Maybe a)) We don't, however, actually use the fact that (Maybe a) is

Re: Array heap objects

nth element and figure out which alternative of the sum it is. But then we'd need some *very* principled operations for constructing arrays; the usual unrestricted mutation approach is not going to work at all. On Thu, Oct 8, 2020, 3:12 PM Ben Gamari wrote: > David Feuer writes: > > > Ah,

Re: Array heap objects

not sure that's so useful if we can't get a little bit of unboxed (non-pointer) stuff in there too. On Thu, Oct 8, 2020, 8:32 AM Ben Gamari wrote: > On October 7, 2020 2:02:53 PM EDT, David Feuer > wrote: > >Yes, the bitmap structures used to encode the structure of stack > >f

Re: Array heap objects

Yes, the bitmap structures used to encode the structure of stack frames. These *look* like they might be reusable for mix-and-match arrays in Haskell-land. If so, that could be a pretty cheap new feature. On Wed, Oct 7, 2020 at 1:37 PM Ben Gamari wrote: > > David Feuer writes: > >

Array heap objects

It appears that the RTS has more flexibility in its array representations than users can access through primops. In particular, there are "pointers-first" and "bitmapped" arrays. Are these used for the evaluation stack or something? I'd be very interested in getting user access to some of this

Re: Help making exception-related primops open-kinded

e useful -- but should be *prominently* document in the RTS C > code that implements them. > > I'm afraid I don't know what "some kind of staging issue" is. > > Simon > > | -Original Message- > | From: ghc-devs On Behalf Of David Feuer > | Sent: 02 Octo

Help making exception-related primops open-kinded

I'm pretty sure raiseIO#, catch#, maskAsyncExceptions#, and so on can have open-kinded results. For example, we currently have catch# :: (State# RealWorld -> (# State# RealWorld, a #) ) -> (b -> State# RealWorld -> (# State# RealWorld, a #) ) -> State# RealWorld -> (# State# RealWorld, a

Re: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released

Will this be updated to the latest containers before release? It's two versions behind at the moment. On Mon, Sep 28, 2020, 3:14 PM Ben Gamari wrote: > Hello all, > > The GHC team is very pleased to announce the availability of the first > alpha release in the GHC 9.0 series. Source and binary

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

That's not a lot of lead time. On Wed, Mar 18, 2020, 2:47 PM Carter Schonwald wrote: > hey everyone, because so much important stuff for the community, it makes > sense to add 2fa required for the org, are there any good reasons to either > wait to do this, or not do it? Feedback welcome! > >

Selector thunks again

The fragility of this feature remains frustrating. A few days ago, I wrote this code for building a complete binary tree from its breadth-first traversal. (This is an improvement of a version by Will Ness.) data Tree a = Empty | Node a (Tree a) (Tree a) deriving Show -- An infinite list

Re: haskell/bytestring stalled?

One thing that would help a bit, I imagine, would be to improve the treatment of unsafeDupablePerformIO in GHC so that bytestring can drop the fragile accursedUnutterablePerformIO without significant performance loss. There's been some discussion about how to do so, but no resolution has been

Re: atomicModifyMutVar2

gt; wired into very innards of ghc type system implementation? (by which i mean > that most / all primops currently are pretty conservative in terms of the > range of ghc type system features they use) > > > On Wed, Oct 16, 2019 at 1:51 PM David Feuer wrote: > >> Wh

Re: atomicModifyMutVar2

like a”, restricting to pairs alone. This didn’t form part >of the proposal, and was never documented. >- Add a bit more clarity to the documentation, so it’d clear what must >be forced. > > > > Any objections? > > > > Simon > > > > *Fro

Re: atomicModifyMutVar2

Actually, maybe we can do better! We don't inherently need the function to be a selector. But to make it more general, we'll need to take some care to make sure to produce good code when it *is* a selector. On Fri, Oct 11, 2019, 6:59 PM David Feuer wrote: > I don't remember what documentat

Re: atomicModifyMutVar2

r# Int > > > > atomicModifyMutVar2# mv $ \a -> > > let foo = f a > > in (g foo, foo) > > > > Now, if f is expensive, *and g is not invertible*, then sharing foo might > be useful. It’s hard to think of a credible example, though. Regardless, &g

Re: atomicModifyMutVar2

On Fri, Oct 11, 2019, 11:08 AM Simon Peyton Jones wrote: > David > > I’m deeply puzzled atomicModifyMutVar2#. I have read the proposal > , > and the comments in primops.txt.pp (reproduced below). >

Re: `StablePtr` in `ST`

You also need to avoid inspecting the StablePtr itself, which is just a number, to maintain purity. The whole thing is a bit weird. Why do you want this anyway? On Wed, Aug 21, 2019, 7:39 AM David Feuer wrote: > So something like > > newtype StablePtr a = StablePtr (StablePtrST

Typed hole improvements

I've been playing around with 8.6.3, and I've really been appreciating the improvements in typed hole messages. Both the information about constraints and the suggestions for filling the holes have proven valuable in heavily typish programming. Thanks! One thing that's still not where I'd like it

Re: The future of Phabricator

What's to prevent GitLab from doing what Phabricator has once enough companies have committed to it? ⁣David Feuer Well-Typed Consultant​ On Oct 30, 2018, 12:55 AM, at 12:55 AM, Ben Gamari wrote: > >TL;DR. For several reasons I think we should consider alternatives to > Phabri

Re: [ANNOUNCE] GHC 8.4.4 released

On Fri, Oct 26, 2018 at 4:43 PM Carter Schonwald wrote: > > Hey David, i'm looking at the git history andit doesn't seem to have any > commits between 8.4.3 and 8.4.4 related to the dataToTag issue > > does any haskell code in the while trigger the bug on 8.4 series? I don't think anyone knows.

Re: [ANNOUNCE] GHC 8.4.4 released

Did  this release fix the dataToTag# issue? I think that has a number of people concerned. On Oct 18, 2018, 11:46 AM, at 11:46 AM, Ben Gamari wrote: >Jens Petersen writes: > >> On Mon, 15 Oct 2018 at 07:17, Ben Gamari wrote: >>> The GHC team is pleased to announce the availability of GHC

Re: Stable name allocation

Simon seems a bit busy right now. Can anyone else advise me on the basics of heap allocation in primops? On Tue, Sep 25, 2018 at 1:42 PM, David Feuer wrote: > Let's forget about allocate(). I can definitely handle this part in > C--. But I'm still lost in the macros and such. For exampl

Re: Heap allocation in the RTS

and pass the value to the RTS > function you're implementing. > > Ömer > > David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde > şunu yazdı: > > > > Aha! Okay. How do I get the current capability to pass to that? I guess > I should probably perform a heap check before

Re: Heap allocation in the RTS

> Ömer > > > David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde > şunu yazdı: > > > > I'm working on re-implementing the stable name system. For the new > design, it seems much cleaner to allocate stable names in lookupStableName > (in rts/StableName.c) rather than in the C-- c

Heap allocation in the RTS

I'm working on re-implementing the stable name system. For the new design, it seems much cleaner to allocate stable names in lookupStableName (in rts/StableName.c) rather than in the C-- code that calls it. But I haven't seen RTS code that does heap allocation. Is it possible? If so, how do I do

Re: ForeignPtr representation

wrote: > Wouldn't this mean that unpacking a ForeignPtr is one word longer than it > is now? That would have a big impact on ByteString. > > What do you think is redundant in the current representation? > > Cheers > Simon > > On Wed, 5 Sep 2018 at 00:23, David Feuer wrote: &

ForeignPtr representation

I'm trying, and failing, to understand why ForeignPtr is defined the way it is. It all seems rather complicated and redundant. I was thinking we might want to switch to something simpler and more explicit, like this: data ForeignPtr a = ForeignPtr { fptr :: !(Ptr a) -- What we point to froot

Unpacking coercions

I had an idea for how we might be able to unpack coercions in a limited and conservative way that doesn't get into the general problems of unpacking constraints. Would this make sense? 1. Move the definition of Coercion from Data.Type.Coercion to GHC.Magic 2. Magically change the type of the

Bump base version

We need to bump the base version to 4.12.1 to accommodate the StableName update. -- David Feuer Well-Typed ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unlifted primop types

gt; case mkWeak# r# b finalizer s of (# s1, w #) -> (# s1, Weak w #) and the current version should've been mkSimpleWeakIORef r fin = mkWeakIORef r r fin On Thu, Aug 23, 2018, 5:52 PM David Feuer wrote: > Weak pointers to unlifted heap objects are the opposite of dodgy! We have > b

Re: Unlifted primop types

er Int# etc. > > > > As you say, this is too much of a special case to make an invasive change. > > > > I’m quite dubious about making weak poitners to unlifted heap-allocated > objects. I can’t say it’s wrong but it feels dodgy to me. > > > > Simon > > >

Re: Unlifted primop types

The problem is that this also accepts things that aren't pointers at all! We could fix that *for primops* by changing RuntimeRep to something like data RuntimeRep = PtrRep Liftedness | ... But that would only work for primops (at least for now) so it may not be worth the breakage. On Wed,

Re: Unlifted primop types

Huh! It looks like what we currently do for some primops is just use a totally bogus kind. For example, mkWeak# will happily accept an Int# as its first argument. So we *could* follow that precedent and generalize reallyUnsafePtrEquality#, makeStableName#, etc., to accept anything, whether it

Re: Unlifted primop types

I see the definition, but I don't understand it, so I don't know how to adapt it to the less-polymorphic version I need. On Tue, Aug 21, 2018, 4:14 PM Ben Gamari wrote: > David Feuer writes: > > > But how do I have to build something like "openAlphaTyVar" for

Re: Unlifted primop types

But how do I have to build something like "openAlphaTyVar" for TYPE 'UnliftedRep in the primitive space? I don't understand the toolkit. On Tue, Aug 21, 2018, 11:07 AM Ben Gamari wrote: > David Feuer writes: > > > On Monday, August 20, 2018 12:11:14 PM EDT Simon Peyto

Re: Stable name equality

On Tue, Aug 21, 2018, 4:32 AM Simon Peyton Jones wrote: > That's explained in the paper. A StableName# is a pointer to a stable name > object in the heap that *contains* an index into the stable name table. > Basically, the garbage collector needs to know whether a stable name is > alive or not,

Re: Stable name equality

On Tue, Aug 21, 2018, 3:39 AM Simon Peyton Jones wrote: > > Actually I'm confused. Currently we have > > data StableName a = StableName (StableName# a) > > I believe (but there is no documentation to state) that the (StableName# > a) > * Has kind (TYPE UnliftedRep) > * Is the index of the

Re: Stable name equality

I had another thought. If we want, I believe we can make the stable name mechanism considerably more compact by giving up on a flat array representation for the stable name table. The flat representation means that enlarging the table moves all its entries. Suppose we instead choose some shallow

Re: Unlifted primop types

On Monday, August 20, 2018 12:11:14 PM EDT Simon Peyton Jones via ghc-devs wrote: > I don’t quite know how primops.txt.pp is processed, but perhaps by > utils/genprimopcode. You may need to update the syntax a bit? The whole thing is a mystery to me. Whatever it's doing seems to generate code

Re: Stable name equality

On Monday, August 20, 2018 11:56:44 AM EDT Simon Peyton Jones via ghc-devs wrote: > I defer to SimonM but IIRC each stable name corresponds to an entry in the > stable-name table; the index in the table is the “stable” thing in a stable > name. So I bet that comparison compares these indices.

Should StablePtr# have its own kind?

Currently, StablePtr# :: Type -> TYPE 'AddrRep The fact that a stable pointer table index has the same size as a pointer seems somewhat coincidental. Would it make sense to add a `StablePtrRep` constructor to `RuntimeRep` and use that? That should allow StablePtr# to change its representation

Unlifted primop types

I'm trying to implement a single primop to replace sameMutVar#, sameMutableArray#, etc. The primop should have type unliftedPtrEquality# :: forall (a :: TYPE 'UnliftedRep). a -> a -> Int# Unfortunately, I don't see a way to express this type in primops.pp.txt. Is it possible? If not,

Re: accuracy of asinh and atanh

/atanh as well. I > >> > believe the reason we don't currently is that atanh was only > >> > standardized in C99, which we only started requiring a few releases ago. > >> > Perhaps this is ultimately the right direction. > >> > > >> > Cheers, > >> > > >> > - Ben > >> ___ > >> ghc-devs mailing list > >> ghc-devs@haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > -- David Feuer Well-Typed ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we have primitive fill-once variables?

Thinking this through some more, I see real trade-offs between the two approaches. The names I've assigned them are for reference only, and not intended to claim or assign any credit. Approach 1 (Feuer style) The IVar is pretty much just a stripped-down MVar. Features: * Should be pretty

Re: Should we have primitive fill-once variables?

On Friday, June 29, 2018 2:13:39 PM EDT Joachim Breitner wrote: > I don’t know! Maybe the GC can treat a filled IVar differently (because > it is no longer mutable?) But really, I don't know :-) That's a very good point. If we turn the IVar into a pure value, then it loses its "dirty" bit and

Re: Should we have primitive fill-once variables?

On Friday, June 29, 2018 12:54:23 PM EDT David Feuer wrote: > The unboxed tuple allows the value to be extracted from the IVar without > being forced. If, however, we want QVars, we can always simulate that using > accursedUnutterablePerformIO: Actually, this might be silly,

Re: Should we have primitive fill-once variables?

On Friday, June 29, 2018 12:19:53 PM EDT Carter Schonwald wrote: > i'm a little confused, whats the order of reads here? > Mvars have write wins, whats the order here? last writer runs first, first > writer runs last? (wouldn't there be starvation issues?) Writes would occur in no particular

Re: Should we have primitive fill-once variables?

On Friday, June 29, 2018 11:51:07 AM EDT Joachim Breitner wrote: > when reading the subject I was expecting something like this: > >-- | pure! but blocks until the IVar is written >readIVar :: IVar a -> a > >-- | tries to write to an IVar. >-- Succeeds if it is empty (returning

Should we have primitive fill-once variables?

IVars (write-once variables) can be useful for various purposes. In Haskell, they can be implemented using MVars. But MVars are not the lightest things in the world. I'm wondering if it might pay to implement something much lighter primitively. Here's a sketch of some things I'll tentatively

atomicWriteIORef

Currently, atomicWriteIORef is implemented using atomicModifyIORef. That seems pretty heavy for the job, allocating closures and forcing thunks. Is there a reason not to do it with casMutVar#? ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Open up the issues tracker on ghc-proposals

oal of fleshing it out before > > committee submission. If it becomes necessary, we can furnish a tag to > > label these, but I'm honestly not sure we'll need to. > > > > Richard > > > > > On May 1, 2018, at 2:24 PM, David Feuer <david.fe...@gmail.com> wrote

Re: Open up the issues tracker on ghc-proposals

es necessary, we can furnish a tag to > label these, but I'm honestly not sure we'll need to. > > Richard > > > On May 1, 2018, at 2:24 PM, David Feuer <david.fe...@gmail.com> wrote: > > > > Sometimes, a language extension idea could benefit from some communit

Open up the issues tracker on ghc-proposals

Sometimes, a language extension idea could benefit from some community discussion before it's ready for a formal proposal. I'd like to propose that we open up the GitHub issues tracker for ghc-proposals to serve as a place to discuss pre-proposal ideas. Once those discussions converge on one or a

Re: [core libraries] Re: Name for unary unboxed one-tuple

#) Int Bool etc. > > > > Simon > > > > *From:* David Feuer <david.fe...@gmail.com> > *Sent:* 25 April 2018 18:38 > *To:* Simon Peyton Jones <simo...@microsoft.com> > *Cc:* Edward Kmett <ekm...@gmail.com>; Andrew Martin < > andrew.thadd...@gmail

Re: [core libraries] Re: Name for unary unboxed one-tuple

One question I don't remember seeing resolved. Will we still be able to use the old data constructor syntax and (fully applied) type constructor syntax? These are used a good bit in the wild. On Wed, Apr 25, 2018, 1:34 PM Simon Peyton Jones via Libraries < librar...@haskell.org> wrote: > OK

Re: primitive library

I think the areas in the primitive library demonstrate a part of the array design space that seems to have gone relatively unexplored in Haskell: plain old vectors. Unlike the vector library, there is no stream fusion framework. Unlike the array library, there is no class-based reliance on

CI builds failing

It looks like the recent differential builds are all failing like this: compiler/main/DynamicLoading.hs:79:19: warning: [-Wunused-matches] Defined but not used: ‘hsc_env’ | 79 | initializePlugins hsc_env df | ^^^ ghc: panic! (the 'impossible' happened) (GHC

Re: Missed beta reductions

From: David Feuer <da...@well-typed.com> Date: 3/27/18 11:28 PM (GMT+01:00) To: Simon Peyton Jones <simo...@microsoft.com> Cc: ghc-devs@haskell.org Subject: Re: Missed beta reductions On Tuesday, March 27, 2018 7:55:02 AM EDT Simon Peyton Jones wrote: > Yes, it’s possible that

Re: Missed beta reductions

On Tuesday, March 27, 2018 7:55:02 AM EDT Simon Peyton Jones wrote: > Yes, it’s possible that he sequence you are seeing is what is happening to > you. But why is that not what you want to see? What are you trying to > achieve? > > Since this function might be applied to many different

RE: Missed beta reductions

n INLINE CONLIKE [0]. Shouldn't that tell GHC that duplicating it is fine? I really want to see it for RULES. David FeuerWell-Typed, LLP Original message From: Simon Peyton Jones <simo...@microsoft.com> Date: 3/26/18 7:14 PM (GMT-05:00) To: David Feuer <da...@well-type

Missed beta reductions

What's the best way to find spots where GHC saw a redex and choose not to beta reduce? Is there a flag for that? It could be useful when trying to figure out why rules aren't firing. David FeuerWell-Typed, LLP___ ghc-devs mailing list

Re: [Haskell] The Haskell Report: who maintains it?

We also have an inconsistency between the textual descriptions of accumArray and accum and their reference implementations. I recently changed GHC's implementations to better match the text (for efficiency reasons), but the reference implementations should be adjusted too. On Thu, Mar 15, 2018 at

Re: package01e failure

The Phabricator differential validated successfully, so that's somewhat surprising. David FeuerWell-Typed, LLP Original message From: Simon Peyton Jones via ghc-devs Date: 2/7/18 4:54 AM (GMT-05:00) To: ghc-devs Subject:

Strict unlifted types

Sometimes there's an awkward expressive tension between saying that a type is *unboxed* and saying that it is *strict* in a field. For example, I can write data SMaybe a = SNothing | SJust !a or I can write type Maybe# a = (# (# #) | a #) but there doesn't seem to be a way to simultaneously

Re: rolling span and groupBy for lists

This is the wrong list. You probably meant to email haskell-cafe or perhaps librar...@haskell.org. David FeuerWell-Typed, LLP Original message From: Harendra Kumar Date: 2/4/18 10:50 PM (GMT-05:00) To: ghc-devs@haskell.org Subject: rolling span

GHC builds are broken

The Linux build has been failing with a segfault. It looks to me as though this started with 0e022e56b130ab9d277965b794e70d8d3fb29533: Turn EvTerm (almost) into CoreExpr. ___ ghc-devs mailing list ghc-devs@haskell.org

RE: Implementing pattern synonym constructor signatures

ton Jones <simo...@microsoft.com> Date: 1/15/18 6:36 PM (GMT-05:00) To: David Feuer <da...@well-typed.com> Cc: ghc-devs@haskell.org Subject: RE: Implementing pattern synonym constructor signatures 0. Parsing. I wasn't actually able to find the code that parses pattern synonyms. Can s

Re: Implementing pattern synonym constructor signatures

Never mind about parsing. It looks like the parser is already doing what it needs to do and I need to look to RdrHsSyn.hs. David FeuerWell-Typed, LLP Original message From: David Feuer <da...@well-typed.com> Date: 1/15/18 2:10 PM (GMT-05:00) To: Simon Peyton Jones

Re: Implementing pattern synonym constructor signatures

See the accepted proposal:  https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0005-bidir-constr-sigs.rst David FeuerWell-Typed, LLP Original message From: Matthew Pickering <matthewtpicker...@gmail.com> Date: 1/15/18 3:27 PM (GMT-05:00) To: David

Implementing pattern synonym constructor signatures

Over the past week I've started digging into the code that implements pattern synonyms with an eye toward implementing the pattern synonym construction function signature proposal. I think I understand a decent amount of what's going on most places. However, I don't understand enough about type

Re: Long standing annoying issue in ghci

It sounds like this should be added to the GHCi documentation, even if it's not strictly about GHCi. David FeuerWell-Typed, LLP Original message From: Evan Laforge Date: 12/5/17 4:49 PM (GMT-05:00) To: Brandon Allbery Cc:

Re: Can strict ST break referential transparency?

If there is indeed a problem, I suspect the right way to fix it is to make sure that no partially evaluated thunk is ever resumed twice. Inter-thread exceptions are presumably rare enough that we don't have to worry *too* much about their cost. David FeuerWell-Typed, LLP Original

Re: GHCi recompilation avoidance UI

wrote: > On 31 October 2017 at 15:42, David Feuer <da...@well-typed.com> wrote: > > > Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now > > refuses to load optimized > > code unless -fobject-code (and optimization flags) are enabled. I propose >

Re: Linux failure

Digging around online, I suspect that you may not have the GNU C++ compiler installed at all. Take this with a shaker of salt. David FeuerWell-Typed, LLP Original message From: Simon Peyton Jones via ghc-devs Date: 11/20/17 8:14 AM (GMT-05:00) To:

Re: True multi stage Haskell

I don't know anything myself, but if you're doing anything remotely related to Haskell and macro systems, you should probably read up on what Alexis King (AKA lexi-lambda) has been up to lately, and maybe get in touch with her. David FeuerWell-Typed, LLP Original message From:

Bringing some observable sharing to GHCi

The :sprint, :print, and :force commands in GHCi fall into infinite loops when confronted by cyclical data. This bit me hard in https://phabricator.haskell.org/D4085 because that produces cyclical TypeReps, which is trouble for (e.g.) the test break011 which tries to :force a SomeException (which

Re: Including libffi as a submodule

Sorry; wasn't thinking straight! David FeuerWell-Typed, LLP Original message From: "Boespflug, Mathieu" <m...@tweag.io> Date: 9/28/17 3:56 AM (GMT-05:00) To: David Feuer <da...@well-typed.com> Cc: ghc-devs <ghc-devs@haskell.org> Subject: Re: Inc

Re: Including libffi as a submodule

On Tuesday, September 26, 2017 9:38:11 PM EDT Ben Gamari wrote: > Numerous attempts have > been made to get the libffi maintainers to cut a new release but sadly > no progress has been made in over six months of trying. Has anyone followed the process described in the somewhat poorly named

  1   2   3   >