1. 8

  2. 1

    Interesting; I’ve used GHC Core plugins myself, for dumping out syntax trees as s-expressions ( http://chriswarbo.net/git/ast-plugin/ )

    I’ve also seen this “beacon” technique used in ghc-dup ( https://hackage.haskell.org/package/ghc-dup ), although that works at the C– level, and it doesn’t work on newer versions of GHC since the way names are encoded has changed (dubbed ‘z encoding’; no relation to https://en.wikipedia.org/wiki/Z-order_curve ). I’ve tried to update it ( http://chriswarbo.net/git/ghc-dup/ ) to use the new scheme, which includes the hash of dependencies rather than just the package name, but it doesn’t look like the required info (the package hashes) is available to the C– when it’s compiled :(

    One question I’d have is how this would work with polymorphism, e.g. for functions like a -> b. I assume that actual use-sites must be monomorphic (e.g. like the Double -> Double example), but would GHC allow us to compile e.g. a polymorphic library function, which just-so-happens to use inline-java inside? Perhaps that’s what “a machinery of type classes” refers to (the ‘jvm’ link is broken; looks like it should point to https://github.com/tweag/inline-java/tree/master/jvm )