Pattern synonym thoughts

There are two features I think would make pattern synonyms even nicer: 1. If a pattern synonym is defined in the same module as one of the type constructors in the type of thing it matches, then it should be possible to export it "attached" to one or more of those constructors (normally but not

Missing definitions of associated types

It seems to be that a missing associated type definition should be an error, by default, rather than a warning. The current behavior under those circumstances strikes me as very strange, particularly for data families and particularly in the presence of overlapping. {-# LANGUAGE TypeFamilies #-}

Re: Type class for sanity

t, too. > > But I suggest a different name. Ground? Terminating? NormalForm? > Irreducible? ValueType? I don't love any of these, but I love Sane less. > > On Jan 24, 2016, at 4:24 PM, David Feuer <david.fe...@gmail.com> wrote: > > > Since type families can be stuck, it'

Re: Type class for sanity

You're correct. Please forget that name. On Jan 25, 2016 12:33 PM, "wren romano" wrote: > On Mon, Jan 25, 2016 at 7:34 AM, Richard Eisenberg > wrote: > > But I suggest a different name. Ground? Terminating? NormalForm? > Irreducible? ValueType? I

Re: Type class for sanity

, but the possibility of stuckness defeats it as its currently written. On Jan 25, 2016 1:01 AM, "Jeffrey Brown" <jeffbrown@gmail.com> wrote: > "Stuck type" is proving difficult to Google. Do you recommend any > references? > > On Sun, Jan 24, 2016 at 1:24

RE: Allow ambiguous types (with warning) by default

> | wrote: > | > If you aren't the one writing the code that can't be called you may > | > never see the warning. It'll be tucked away in a cabal or stack > | build > | > log somewhere. > | > > | > -Edward > | > > | > On Sun, Dec 6

Non-exported class constraints in errors

The latest implementation of Data.Constraint.Forall uses type family Forall (p :: k -> Constraint) :: Constraint where Forall p = Forall_ p class p (Skolem p) => Forall_ (p :: k -> Constraint) instance p (Skolem p) => Forall_ (p :: k -> Constraint) The trouble is that errors relating to Forall

Re: Allow ambiguous types (with warning) by default

e > doing something wrong at the definition site or the call site. With the > status quo it complains at the right time that you aren't going to sit there > flailing around trying to fix a call site that can never be fixed. > > -Edward > > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer <

Re: Allow ambiguous types (with warning) by default

ou aren't the one writing the code that can't be called you may never > see the warning. It'll be tucked away in a cabal or stack build log > somewhere. > > -Edward > > On Sun, Dec 6, 2015 at 12:06 AM, David Feuer <david.fe...@gmail.com> wrote: >> >> No, I want

Re: ambiguous type stuff

I think I didn't explain myself well enough. I'm not talking about expanded defaulting, although that may be tied up with the same mechanisms. Perhaps the best thing is just to work on the error message text for certain ambiguous type situations. Notably, situations where adding a proxy argument

Allow ambiguous types (with warning) by default

The ambiguity check produces errors that are quite surprising to the uninitiated. When the check is suppressed, the errors at use sites are typically much easier to grasp. On the other hand, there's obviously a lot of value to catching mistakes as soon as possible. Would it be possible to turn

Re: Context for typed holes

> > Cheers, > Andres > > On Fri, Oct 23, 2015 at 7:48 AM, David Feuer <david.fe...@gmail.com> > wrote: > > I opened https://ghc.haskell.org/trac/ghc/ticket/10954 for this. #9479, > by > > Dominique Devriese, is complementary--she wants instance information fo

Re: Coercion logic

ould know that (Coercible a b > <=> Coercible b a). Do you have a concrete example of where it's not doing > this? Have you tested against HEAD? > > Thanks, > Richard > > On Oct 22, 2015, at 9:56 AM, David Feuer <david.fe...@gmail.com> wrote: > >> At pres

Coercion logic

exactly the same run-time representation, and because People Wiser Than Me believe Coercible should *always* remain symmetric. My (admittedly reptilian) brain wonders what it would take to tell the type checker that forall a b . Coercible a b ~ Coercible b a and have it over with. David Feuer

Re: Context for typed holes

, 2015 01:15, "Manuel M T Chakravarty" <c...@justtesting.org> > wrote: > > > > I think, this is a good point. Maybe you should make a ticket for it. > > #9479, I think. > > Cheers, > Andres > > >> David Feuer <david.fe...@gmail.com>: &

Moving forall with coerce

It appears, as far as I can tell, that GHC can't move a forall past an -> with coerce. I was playing around with the MonadTrans instance for Codensity, wanting (essentially) to write lift = coerce (>>=) This is legal: instance MonadTrans Codensity where lift = frob frob :: forall m a . Monad

Context for typed holes

Unless something has changed really recently that I've missed, the typed holes messages are missing some really important information: instance information for types in scope. When I am trying to fill in a hole, I look to the "relevant bindings" to show me what pieces I have available to use.

MIN_VERSION macros

he version based on the GHC version. This works reasonably well for base, ghc-prim, containers, etc., but not so well/at all for others. Would there be some way to get GHC itself to provide these macros to all modules that request CPP? David Feuer __

Re: Deriving Contravariant and Profunctor

e investigated adding TH code-generation for the contravariant package, and > ultimately rejected it on these grounds. > > https://github.com/ekmett/contravariant/issues/17 > > -Edward > > > > On Fri, Sep 11, 2015 at 12:49 PM, David Feuer <david.fe...@gmail.com>

Re: Access to class defaults and derived instances

a hard time fully understanding this request without more context. But I do think I understand the last paragraph. And it seems bound to create class incoherence. What if someone else *does* write that orphan instance you're avoiding writing? Richard On Aug 22, 2015, at 12:54 PM, David Feuer

Access to class defaults and derived instances

From time to time, a library lacks an instance for something that I want. For example, I may need to convert data Foo = Bar (Vector Baz) to FishFood, but (to avoid unreasonable dependencies) Vector doesn't have a ToFishFood instance, so I can't just write instance ToFishFood Foo and (using

Re: MonadFail proposal (MFP): Moving fail out of Monad

Pattern matching on `undefined` is not like pattern match failure. Single-constructor types are only special if they're unlifted: `newtype` and GHC's unboxed tuples are the only examples I know of, and you can't use unboxed tuples in this context. On Thu, Jun 11, 2015 at 11:28 AM, Wolfgang

Re: Behavior change of Data.Char

I don't think so. There's no guarantee that future versions will maintain it, and I don't know that we want to take responsibility for continually checking on that. David On Feb 20, 2015 Simon Peyton Jones wrote: It'd be good to document this condition/invariant in the Haddocks, wouldn't it?!

Merge FlexibleContexts with FlexibleInstances?

In my limited experience thus far, it seems to me that a substantial majority of modules that start out needing one of these end up needing the other one too. They appear to be two sides of the same coin, each allowing for (slightly) more powerful termination checking. Should the two just be made

Re: What is the story behind the type of undefined?

. See https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds for more details.) Hope this helps, Adam On 01/02/15 18:54, David Feuer wrote: If I define {-# LANGUAGE MagicHash #-} g :: Int# - Int g 3# = 3 myUndefined = undefined then this gives a sensible type error about a kind mismatch

What is the story behind the type of undefined?

If I define {-# LANGUAGE MagicHash #-} g :: Int# - Int g 3# = 3 myUndefined = undefined then this gives a sensible type error about a kind mismatch: usual :: Int usual = g myUndefined but this, oddly enough, compiles: peculiar :: Int peculiar = g undefined GHCi and the definition in

Re: vectorisation code?

Richard Eisenberg wrote: Here's an alternate suggestion: in SimplCore, keep the call to vectorise around, but commented out (not just with CPP, for better syntax highlighting). Include a Note explaining what `vectorise` does and why it's not there at the moment. However, move the actual

Milestones

I took the liberty of pushing back the milestones for a few tickets that looked unlikely to be acted on for 7.10.1, based on a combination of severity, recent activity, and perceived intrusiveness. If anyone objects, please move them back. #9314: Each object file in a static archive file (.a) is

Re: seq#: do we actually need it as a primitive?

On Thu, Jan 8, 2015 at 8:42 AM, Roman Cheplyaka r...@ro-che.info wrote: Also, where can I find the 'instance Monad IO' as understood by GHC? grep didn't find one. It's in GHC.Base. ___ ghc-devs mailing list ghc-devs@haskell.org

seq#: do we actually need it as a primitive?

I've read about the inlining issues surrounding Control.Exception.evaluate that seem to have prompted the creation of seq#, but I'm still missing something. Isn't seq# a sthe same as let !a' = a in (# s, a' #) ? David ___ ghc-devs mailing list

Re: The future of the Haskell98 and Haskell2010 packages

I think you're right, and that's a strong reason to come up with an update to the Haskell Report. Include in it, at least: -- Big-ticket items 0. Monoid 1. Foldable, Traversable 2. Applicative 3. Applicative = Monad -- side notes 4. inits = map reverse . scanl (flip (:)) [] -- efficiency—not

Re: [GHC] #9781: Make list monad operations fuse

On Nov 11, 2014 3:56 AM, Kim-Ee Yeoh k...@atamo.com wrote: From the patch fragment at https://phabricator.haskell.org/D455?id=1311#inline-3123 What's the justification for expanding out the definition of mapM from sequence . map f into do-notation and duplicated code? Observe how mapM now

RE: [GHC] #9781: Make list monad operations fuse

our consumer, they will not fuse. I think Simon's simplifier changes a few months ago helped with this issue, but I don't know that it is (or can ever be) resolved completely. On Nov 11, 2014 11:54 AM, David Feuer david.fe...@gmail.com wrote: On Nov 11, 2014 6:04 AM, Simon Peyton Jones simo

Re: RFC: Dropping Windows XP support

+1. Windows XP was Microsoft's most successful OS thus far, but it's pretty much dead now. One potentially related potential concern: how will this change affect Wine support? On Fri, Nov 7, 2014 at 1:16 PM, Austin Seipp aus...@well-typed.com wrote: Hi all, This is a quick discussion about

RE: thenIO removal

Simon Peyton Jones wrote: It's not a big deal. You can probably replace both those bindIOName uses with bindMName (i.e (=)), in TcRnDriver. That will just make GHCi generate code with uses of overloaded (=) that must be evaluated, rather than calling bindIO directly. It should work just

thenIO removal

GHC.Base has a function, thenIO, that isn't used anywhere in the libraries or compiler, and isn't exported anywhere public. But for some reason, it's listed in compiler/prelude/PrelNames.lhs, which causes a validation failure if I remove it. Is there a reason that a completely unused function is

Re: Understanding core2core optimisation pipeline

On Thu, Oct 30, 2014 Jan Stolarek wrote: 2. First pass of full laziness is followed by floating in. At that stage we have not yet run the demand analysis and yet the code that does the floating-in checks whether a binder is one-shot (FloatIn.okToFloatInside called by FloatIn.fiExpr AnnLam

Re: Call Arity, oneShot or both

Simon Peyton Jones wrote: But since it is plausible that there are cases out there where it might help, even if just a little, we could go forward ?unless the implementation becomes ugly. Based on our experience with Call Arity, it's much more likely that it will help a lot in a few cases

Is USE_REPORT_PRELUDE still useful?

A lot of code in GHC.List and perhaps elsewhere compiles differently depending on whether USE_REPORT_PRELUDE is defined. Not all code differing from the Prelude implementation. Furthermore, I don't know to what extent, if any, such code actually works these days. Some of it certainly was not

Re: Call Arity, oneShot, or both

Joachim Breitner כתב That would be great! But do we have evidence of this user-written code that benefits? So far I have only seen relevant improvement due to list-fusion a left-foldish function. I was under the impression that the transformation was much more general than that, improving

Re: Call Arity, oneShot, or both

There is also the option of combining both. Then we do not get the regression, but still the improvement for fft2: I *definitely* think we should leave Call Arity in place by default unless and until something strictly better comes along. One very nice feature is that it works for a lot of

Improving specialization, redux

I spoke with Simon today, and I think I have a bit of a better idea now of what's going on with specialization, and why it sometimes fails to specialize things as much as it could. Apparently, the replacement of (sel @ type dict) by sel.type is accomplished by the use of a rewrite rule generated

Re: Avoiding the hazards of orphan instances without dependency problems

, so they certainly are complementary and could co-exist. On Tue, Oct 21, 2014 at 9:11 AM, David Feuer david.fe...@gmail.com wrote: As I said before, it still doesn't solve the problem I'm trying to solve. Look at a package like criterion, for example. criterion depends

Re: Avoiding the hazards of orphan instances without dependency problems

control of imports and exports is. Unless the problems turn out to be impossible to overcome. Janek Dnia środa, 22 października 2014, David Feuer napisał: You're not the first one to come up with this idea (and I don't know who is). Unfortunately, there are some complications. I'm pretty

Re: Avoiding the hazards of orphan instances without dependency problems

On Oct 21, 2014 1:22 PM, John Lato jwl...@gmail.com wrote: Perhaps you misunderstood my proposal if you think it would prevent anyone else from defining instances of those classes? Part of the proposal was also adding support to the compiler to allow for a multiple files to use a single module

RE: Help understanding Specialise.lhs

On Oct 20, 2014 5:05 AM, Simon Peyton Jones simo...@microsoft.com wrote: I’m unclear what you are trying to achieve with #9701. I urge you to write a clear specification that we all agree about before burning cycles hacking code. What I'm trying to achieve is to make specialization work in a

Re: Help understanding Specialise.lhs

$c+. But for some reason, GHC fails to recognize and exploit this fact! I would like help understanding why that is, and what I can do to fix it. On Mon, Oct 20, 2014 at 7:53 AM, David Feuer david.fe...@gmail.com wrote: On Oct 20, 2014 5:05 AM, Simon Peyton Jones simo...@microsoft.com wrote

Avoiding the hazards of orphan instances without dependency problems

Orphan instances are bad. The standard approach to avoiding the orphan hazard is to always put an instance declaration in the module that declares the type or the one that declares the class. Unfortunately, this forces packages like lens to have an ungodly number of dependencies. Yesterday, I had

Re: Avoiding the hazards of orphan instances without dependency problems

, and then modify an imported module later. On Oct 19, 2014 1:05 PM, Brandon Allbery allber...@gmail.com wrote: On Sun, Oct 19, 2014 at 1:02 PM, David Feuer david.fe...@gmail.com wrote: with a flag -XAllowForbiddenInstancesAndInviteNasalDemons One could argue this is spelled

Re: Avoiding the hazards of orphan instances without dependency problems

in a restricted manner). I think I'd prefer this when implementing orphan instances, and probably when writing the pragmas as well. On Mon, Oct 20, 2014 at 1:02 AM, David Feuer david.fe...@gmail.com wrote: Orphan instances are bad. The standard approach to avoiding the orphan hazard

Help understanding Specialise.lhs

me get enough of a sense of it to let me do what I need? Many thanks in advance. David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Avoiding the hazards of orphan instances without dependency problems

your method seems to require having both the class and type in scope, in which case one could simply declare the instance in that module anyway. On Mon, Oct 20, 2014 at 9:29 AM, David Feuer david.fe...@gmail.com wrote: I don't think your approach is flexible enough to accomplish the purpose

T3064 failures

I don't know what's going on, but T3064 is giving some substantial performance trouble, making all the validations fail: max_bytes_used value is too high: ExpectedT3064(normal) max_bytes_used: 13251728 +/-20% Lower bound T3064(normal) max_bytes_used: 10601382 Upper bound

oneShot (was Re: FoldrW/buildW issues)

Just for the heck of it, I tried out an implementation of scanl using Joachim Breitner's magical oneShot primitive. Using the test scanlA :: (b - a - b) - b - [a] - [b] scanlA f a bs = build $ \c n - a `c` foldr (\b g x - let b' = f x b in (b' `c` g b')) (const n) bs

Re: oneShot (was Re: FoldrW/buildW issues)

Yes, and it does a very good job in many cases. In other cases, it's not as good. On Tue, Oct 7, 2014 at 7:59 AM, Sophie Taylor sop...@traumapony.org wrote: Wait, isn't call arity analysis meant to do this by itself now? On 7 October 2014 17:05, David Feuer david.fe...@gmail.com wrote: Just

Re: dropWhileEndLE breakage

—the difference in behavior doesn't matter there. David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: FoldrW/buildW issues

On Sep 12, 2014 2:35 PM, Joachim Breitner m...@joachim-breitner.de wrote: I once experimented with a magic oneShot :: (a - b) - (a - b) function, semantically the identity, but tell the compiler not to share the result of the computation. Using that in the definition of foldl-as-foldr, one can

Re: ghc-devs Digest, Vol 133, Issue 40

Simon Peyton Jones wrote: anywhere, I think. You might want a new HsSyn data type for list with possible leading or trailing commas: data HsCommadList a = HCL Int -- Number of leading commas [a] Int -- Number of trailing commas If we're going to go to

FFI library error building GHC

I keep getting this error. Can anyone help? I tried removing the file as suggested, but it made no difference. /home/dfeuer/GHC/7.8.3.bin/bin/ghc -o utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i

Re: FFI library error building GHC

the libffi.a was in libffi/build/inst/lib64/libffi.a iirc. On Sep 20, 2014, at 8:13 AM, David Feuer david.fe...@gmail.com wrote: I keep getting this error. Can anyone help? I tried removing the file as suggested, but it made no difference. /home/dfeuer/GHC/7.8.3.bin/bin/ghc -o utils/genapply

Where can I stick a dead code elimination rule for quotRemInt#?

As I describe in #9617, GHC's CSE in 7.9 seems to be good enough to let Int and Integer use quot x y = fst (x `quotRem` y) rem x y = snd (x `quotRem` y) And actually get good results in code that uses both the quotient and the remainder. I believe the only thing left to be able to actually

Cleaning up rather silly static arguments

Aside from anything having to do with the foldrW/buildW stuff, I decided to try a little experiment using fusing scanl and reverse (implementations at http://lpaste.net/2416758997739634688 ) When I define scanr f b = reverse . scanl (flip f) b . reverse I get this: scanr1 scanr1 = \ @ a_akP _

Re: FoldrW/buildW issues

Joachim Breitner wrote: Am Samstag, den 13.09.2014, 00:01 -0400 schrieb David Feuer: On Sep 12, 2014 2:35 PM, Joachim Breitner m...@joachim-breitner.de wrote: Interesting. I assumed that some wrap.unwrap=id law would hold, or at least some moral approximation (e.g. disregarding

Re: FoldrW/buildW issues

:08 PM, Dan Doel dan.d...@gmail.com wrote: Which scanl wrapper are you referring to? The first one I figured out was quite wrong in certain ways. But I think the new one is less controversial; it's a lot like the reverse one. On Sun, Sep 14, 2014 at 1:03 PM, David Feuer david.fe...@gmail.com

Re: FoldrW/buildW issues

On Sep 12, 2014 2:35 PM, Joachim Breitner m...@joachim-breitner.de wrote: Interesting. I assumed that some wrap.unwrap=id law would hold, or at least some moral approximation (e.g. disregarding bottoms in an acceptable manner). But if the wrappers have to do arbitrary stuff that can

Re: The list fusion lab

Joachim Breitner wrote: Together with John Wiegly at ICFP, I started to create a list performance laboratory. You can find it at: https://github.com/nomeata/list-fusion-lab Many thanks to you both! This sounds like an excellent idea. I do hope someone figures out a way around the

What is testsuite/tests/rename/should_fail/rnfail018.hs supposed to test?

; the parens after the for-all fooled it class Monad m = StateMonad s m where getState :: m s setState0 :: forall b. (StateMonad (a,b) m = m a) setState0 = getState = \ (l,_r) - return l David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http

Re: Trying to fix an efficiency issue noted in a TODO in SAT.lhs

Joachim Breitner wrote: Did you profile first, and did it show up there? You know, premature optimization... so it might be that your fix is a nice improvement and useful exercise (and very welcome as such), but without much real-world effect. You're right, of course. I read the comment and

Trying to fix an efficiency issue noted in a TODO in SAT.hs

down before choosing the best data structure. Thanks, David Feuer diff --git a/compiler/simplCore/SAT.lhs b/compiler/simplCore/SAT.lhs index a0b3151..aae3e69 100644 --- a/compiler/simplCore/SAT.lhs +++ b/compiler/simplCore/SAT.lhs @@ -67,10 +67,16 @@ import VarSet import Unique import UniqSet

RE: cons/build and making rules look boring

on.) Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David | Feuer | Sent: 30 August 2014 23:05 | To: ghc-devs | Subject: cons/build and making rules look boring | | I think I may have figured out at least part of the reason that | cons

Trouble compiling fibon

I'm trying to compile the fibon benchmark suite, but I'm getting a non-specific permission error. Can anyone give me a clue? == make boot - --no-print-directory; in /home/dfeuer/src/ghc-slowmod/nofib/fibon/Hackage/Bzlib //

RE: Fusion

describe https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky Simon | -Original Message- | From: David Feuer [mailto:david.fe...@gmail.com] | Sent: 20 August 2014 09:33 | To: Simon Peyton Jones | Subject: Re: Fusion | | I'll be happy to try to expand it with some examples

Re: Why isn't ($) inlining when I want?

On Thu, Aug 28, 2014 at 6:22 AM, Simon Peyton Jones simo...@microsoft.com wrote: Oh, now I understand. In loop g = sum . map g $ [1..100] GHC can share [1..10] across all calls to loop, although that nixes fusion. Because each call of loop may have a different g. But in

Why isn't (.) CONLIKE?

allows them to float, but makes RULES continue to work even though they’ve been floated. See the user manual. *From:* Dan Doel [mailto:dan.d...@gmail.com] *Sent:* 28 August 2014 16:48 *To:* Simon Peyton Jones *Cc:* John Lato; David Feuer; ghc-devs *Subject:* Re: Why isn't ($) inlining

Raft of optimizer changes

On Thu, Aug 28, 2014 at 8:00 AM, simonpj wrote I've just pushed a bunch of Core-to-Core optimisation changes that have been sitting in my tree for ages. The aggregate effect on nofib is very modest, but they are mostly aimed at corner cases, and consolidation. Thanks for trying to do

Re: Why isn't ($) inlining when I want?

but id undefined `seq` 1 = undefined On Wed, Aug 27, 2014 at 12:21 PM, David Feuer david.fe...@gmail.com wrote: I just ran that (results attached), and as far as I can tell, it doesn't even *consider* inlining ($) until phase 2. On Wed, Aug 27, 2014 at 4:03 AM, Simon Peyton Jones simo

Why isn't ($) inlining when I want?

preventing this from happening in the PostGentle phase I added? David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [GHC] #9496: Simplify primitives for short cut fusion

Yes, I meant producer there. On Fri, Aug 22, 2014 at 9:36 AM, GHC ghc-devs@haskell.org wrote: #9496: Simplify primitives for short cut fusion -+- Reporter: dfeuer |Owner: dfeuer

The definition of cseProgram

bs' = cseBinds env1 bs Couldn't we replace all that with the following? (Thanks to Cale for suggesting mapAccumL—I was using scanl because I knew it, but it was not a great fit.) cseProgram = snd . mapAccumL cseBind emptyCSEnv David Feuer

Partial recompilation of libraries

I'd like to try out a bunch of little changes to the list stuff in base and get some nofib results for each change. Is there a way to do this without recompiling all of GHC each time? ___ ghc-devs mailing list ghc-devs@haskell.org

RE: [GHC] #9434: GHC.List.reverse does not fuse

, than to create and try to CSE it away. Others have suggested ways of doing so, following the pattern of existing RULES. Simon *From:* David Feuer [mailto:david.fe...@gmail.com] *Sent:* 15 August 2014 16:41 *To:* ghc-devs; Simon Peyton Jones *Subject:* Re: [GHC] #9434: GHC.List.reverse

Re: [GHC] #9434: GHC.List.reverse does not fuse

I'm having trouble when it doesn't fuse—it ends up with duplicate bindings at the top level, because build gets inlined n times, and the result lifted out. Nothing's *wrong* with the code, except that there are multiple copies of it. On Aug 15, 2014 10:58 AM, GHC ghc-devs@haskell.org wrote:

Re: [GHC] #9434: GHC.List.reverse does not fuse

happens? On Fri, Aug 15, 2014 at 11:41 AM, David Feuer david.fe...@gmail.com wrote: I'm having trouble when it doesn't fuse—it ends up with duplicate bindings at the top level, because build gets inlined n times, and the result lifted out. Nothing's *wrong* with the code, except

<    1   2   3