Re: status of rebindable syntax for arrows
On Tue, Oct 14, 2014 at 10:26:46PM +0200, S. Doaitse Swierstra wrote: > The GHC manual already for quite a number of version states: > > • Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever > arr, (>>>), first, app, (|||) and loop functions are in scope. > But unlike the other constructs, the types of these functions must > match the Prelude types very closely. Details are in flux; if you want to use > this, ask! > > When using this feature we get the error: > > "Var/Type length mismatch: >[s{tv aVL} [tv]] >[] > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.3 for x86_64-apple-darwin): > tcTyVarDetails s{tv aVL} [tv] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug"; > > So our question is whether we should really report this as a bug, and/or what > we can do about this. It already has a bug entry: #7828. What would help is to know the kind of use you have in mind, to see whether it fits with the proposed solution. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590
Title: Re: The future of the haskell2010/haskell98 packages - AKA Trac #9590 Hello Brandon, Wednesday, October 1, 2014, 1:02:54 AM, you wrote: On Tue, Sep 30, 2014 at 5:00 PM, Malcolm Wallacewrote: How about doing the honest thing, and withdrawing both packages in ghc-7.10? Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway. There are apparently educators using both, although they're not used much if at all in production. does they need latest GHC version? an option may be to drop support of Haskell'98 in GHC 7.10, then implement superclass proposal in GHC 7.12 and return haskell'98 support -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
status of rebindable syntax for arrows
The GHC manual already for quite a number of version states: • Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! When using this feature we get the error: "Var/Type length mismatch: [s{tv aVL} [tv]] [] ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): tcTyVarDetails s{tv aVL} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug"; So our question is whether we should really report this as a bug, and/or what we can do about this. Thanks for your help, Doaitse ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
optimizing StgPtr allocate (Capability *cap, W_ n)
Hello Glasgow-haskell-users, i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rts/sm/Storage.c#L680 if i correctly understand, it's speed-critical routine? i think that it may be improved in this way: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); /// here starts new improved code: bd = cap->r.rCurrentAlloc; if (bd == NULL || bd->free + n > bd->end) { if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) { } if (bd->free + n <= bd->start + BLOCK_SIZE_W) bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD) goto usual_alloc; } } /// and here it stops usual_alloc: p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } i think it's obvious - we consolidate two if's on the crirical path into the single one plus avoid one ADD by keeping highly-useful bd->end pointer further improvements may include removing bd==NULL check by initializing bd->free=bd->end=NULL and moving entire "if" body into separate slow_allocate() procedure marked "noinline" with allocate() probably marked as forceinline: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); bd = cap->r.rCurrentAlloc; if (bd->free + n > bd->end) return slow_allocate(cap,n); p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } this change will greatly simplify optimizer's work. according to my experience current C++ compilers are weak on optimizing large functions with complex execution paths and such transformations really improve the generated code -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users