Re[2]: [Haskell-cafe] faster compiling for ghc
Hello David, Thursday, November 12, 2009, 10:22:41 AM, you wrote: are you seen hugs, for example? i think that ghc is slow because it's written in haskell and compiled by itself If I understood, Evan is interested in ideas to speed up compilation. As far as I know, hugs is an interpreter, not a compiler. it's impossible to interpret haskell - how can you do type inference? hugs, like ghci, is bytecode interpreter. the difference is their implementation languages - haskell vs C -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] faster compiling for ghc
Hello Neil, Thursday, November 12, 2009, 1:57:06 PM, you wrote: I'd really love a faster GHC! there are few obvious ideas: 1) use Binary package for .hi files 2) allow to save/load bytecode 3) allow to run program directly from .hi files w/o linking 4) save mix of all .hi files as program database using mysql or so second one may be useful for hugs too. also, once i have asked you for CPP support in winhigs ;) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] faster compiling for ghc
Hello Rafal, Thursday, November 12, 2009, 3:10:54 PM, you wrote: it's impossible to interpret haskell - how can you do type inference? hugs, like ghci, is bytecode interpreter. the difference is their implementation languages - haskell vs C We use Standard ML for the Isabelle/HOL theorem prover, and it's interpreted, even has an interactive toplevel. It uses type inference, does it not? In fact, in a not-very-serious discussion at some point of what one could replace javascript with for a browser-embedded language, SML came up. ghc also has interactive toplevel. it compiles haskell down to bytecode, though. type inference is a part of compilation process, afaik, ocaml also generates bytecode. don't know about isabelle -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] faster compiling for ghc
Hello Peter, Thursday, November 12, 2009, 3:26:21 PM, you wrote: incremental is just a word. what exactly we mean? ghc, like any other .obj-generating compiler, doesn't recompile unchanged source files (if their dependencies aren't changed too). otoh, (my old ghc 6.6) recompiles Main.hs if imported Sub.hs added new declaration (anyway unused in Main), so it may be improved some way Regarding speeding up linking or compilation, IMO the real speedup you would get from incremental compilation linking. It's okay if the initial compilation linking take a long time, but the duration of next cl iterations should only depend on the number of changes one does, not on the total project size. On Thu, Nov 12, 2009 at 1:10 PM, Rafal Kolanski x...@xaph.net wrote: Bulat Ziganshin wrote: it's impossible to interpret haskell - how can you do type inference? hugs, like ghci, is bytecode interpreter. the difference is their implementation languages - haskell vs C We use Standard ML for the Isabelle/HOL theorem prover, and it's interpreted, even has an interactive toplevel. It uses type inference, does it not? In fact, in a not-very-serious discussion at some point of what one could replace javascript with for a browser-embedded language, SML came up. What makes Haskell so different that it can't be interpreted in the SML style? Sincerely, Rafal Kolanski. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] faster compiling for ghc
On Thu, Nov 12, 2009 at 12:39 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Peter, Thursday, November 12, 2009, 3:26:21 PM, you wrote: incremental is just a word. what exactly we mean? Incremental linking means the general idea of reusing previous linking results, only patching it up with respect to changed obj files. So it's about reducing link times, not compile times. This has various consequences for executable size etc. so not something you'd want to do for release builds I think... Here's the documentation for VC's incremental linking option: http://msdn.microsoft.com/en-us/library/4khtbfyf(VS.80).aspx -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
