Sylvain Henry

Hi @Twinside This topic came up again a few weeks ago in https://groups.google.com/g/diagrams-discuss/c/TRtnvrQaT-k/m/LPq6iqmTBAAJ?pli=1 The following code demonstrates the issue. ```haskell import Codec.Picture import Graphics.Rasterific main :: IO () main =...

For the record, the line is: ``` ghc-Options: -pgml g++ "-optl-Wl,--allow-multiple-definition" "-optl-Wl,--whole-archive" "-optl-Wl,-Bstatic" "-optl-Wl,-lfltkc" "-optl-Wl,-Bdynamic" "-optl-Wl,--no-whole-archive" ```

As of https://gitlab.haskell.org/ghc/ghc/-/commit/41d6cfc4d36ba93d82f16f9a83ea69f4e02c3810, `GHC.IntWord64` module doesn't exist anymore as `Int64/Word64` operations have become regular primops (accessible from `GHC.Exts`).

@Bodigrim I would go even further and use `Word` internally to store the length of a ByteString. It would allow us to remove some silly `assert (l >= 0)`. I'm...

We should really add memcpy/memset/memmove primops into GHC. GHC already has thresholds to inline internal calls (see https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/CmmToAsm/X86/CodeGen.hs#L2194 for memcpy on X86). It could insert unsafe/safe calls with new thresholds...

I don't understand why we need both Ghc/Hsc monads with Session/HscEnv states. It's probably an historical artifact from when `hsc` was a separate program from the `ghc` driver. We should...

Actually Ghc is a state monad but Hsc is only a Reader monad so we should probably keep them separate.

In general no. We can safely lift a `Hsc a` into a `Ghc a` but not the other way around. EDIT: we can if we drop the environment resulting from...

Looking at `parseModule` and `typecheckModule`, both could be in Hsc monad instead of Ghc monad. Only `loadModule` needs to modify the HscEnv (to add the module in the home package...

It could be useful to define `liftHsc :: GhcMonad m => Hsc a -> m a`.