Re: True multi stage Haskell

Hi Tim, About using GHC as a library module, have you see the ongoing work on "native metaprogramming" in GHC at https://ghc.haskell.org/trac/ghc/wiki/NativeMetaprogramming and a child project at https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow There, online code generation

Re: True multi stage Haskell

Hello Tim, I don't know the answers to your questions exactly, but I've played around with something that I think might be related, so I thought I'd share. The example code is here: https://github.com/GaloisInc/galua/blob/master/galua-jit/src/Galua/Micro/Compile.hs This module contains a

RE: Observation on Hadrian's relative performance re current buildsystem

Simon Peyton Jones via ghc-devs writes: > Urk! I expected Hadrian to be faster because it has more accurate > dependencies. > While this is just speculation, this might actually be one of the reasons why the no-op case is slower: in make's case the dependency graph is

Re: True multi stage Haskell

Hi Tim, When you say "multi-stage programming language" do you have a specific calculus in mind? I think this can mean lots of different things to different people. This is a topic I have been interested in recently. Cheers, Matt On Fri, Nov 17, 2017 at 6:05 PM, Tim Sheard

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:

True multi stage Haskell

After many years of hoping someone else would do this, I would like to make GHC into a true multi-stage programming language. Here is how I thought I might approach this. 1) Use the GHC as a library module. 2) Use the LLVM backend. I have no experience with either of these tools. Lets start

RE: Observation on Hadrian's relative performance re current

Hi Herbert, Thanks for the careful performance experiment! Can you please put all the details into the issue tracker so they don't get lost? We have a couple of performance issues open, and we know that there are performance bugs in Hadrian leading to too sequential build (a recent example is

RE: Observation on Hadrian's relative performance re current buildsystem

Urk! I expected Hadrian to be faster because it has more accurate dependencies. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 17 November 2017 13:08 | To: ghc-devs@haskell.org | Subject: Observation

Observation on Hadrian's relative performance re current buildsystem

Hello GHC devs, I took the opportunity to give Hadrian a test-run to see whether it could live up to the big promise of delivering a "more scalable, faster" system than the current GNU Make based system. Unfortunately, my preliminary results don't back this claim, and actually make Hadrian appear