Re: Status of "Improved LLVM backend"

> > > > I don’t know if generating llvm from stg instead of cmm would be a > > > > better > > > > approach, which is what ghcjs and eta do as far as I know. > > > > > > Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty > > > low-level > > > representation compared to STG)?

Re: Status of "Improved LLVM backend"

On Mon, Nov 28, 2016 at 2:43 AM Moritz Angermann wrote: [...] > For the llvm code gen in ghc it’s usually the `_fast` suffix functions. See [1] and > the `genStore_fast` 30 lines further down. My bitcode llvm gen follows that file [1], > almost identically, as can be seen

Re: [ANNOUNCE] GHC 8.0.2 release candidate 1

Jens Petersen writes: > On 26 November 2016 at 07:38, Ben Gamari wrote: > >> http://downloads.haskell.org/~ghc/8.0.2-rc1/ >> > > Thank you, I built it for Fedora 25 (just released last week) and Rawhide: > >

Re: Separating typechecking and type error reporting in two passes?

Hi, I guess the claim is still true: Think about just the amount of code you compile when you install your dependencies. But you are right that when the programmer sits there and waits for a result, that’s when snappyness is important. I don’t expect this change to be human-noticable in terms of

Re: Separating typechecking and type error reporting in two passes?

One concern I have is with the claim that "most compiled programs are type correct". This has emphatically not been my experience while developing Haskell. Often, I edit and recompile to find the next type error to fix, or the new type of the hole; this is especially easy (and automatic) in emacs

Levity polymorphism

Richard. I’ve made a status page for levity polymorphism. Everyone: tag levity-polymorphic tickets with “LevityPolymorphism” keyword. We really need a GHC proposal too… Simon https://ghc.haskell.org/trac/ghc/wiki/LevityPolymorphism ___ ghc-devs mailing

Separating typechecking and type error reporting in two passes?

Hi, the following is a rough idea that I came up with while pondering #12864, which is about better (and fewer!) error messages when the user forgot an argument to a function, or swapped their order. The current scheme of type checking and error reporting is the following (please correct me if

RE: Help needed: Restrictions of proc-notation with RebindableSyntax

Jan, Type checking and desugaring for arrow syntax has received Absolutely No Love for several years. I do not understand how it works very well, and I would not be at all surprised if it is broken in corner cases. It really needs someone to look at it carefully, document it better, and