-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to load external libraries #159
Comments
Let's look at a simpler example which nevertheless reproduces the core issue of not being able to use an external library at runtime:
The easiest way to solve the problem is to use ghc environment files:
|
Now, you're a sophisticated user who knows about
The file specifies the package versions with which cabal built the code, and the package databases where those versions are installed. When this file exists, the ghc library (which hint is based on) uses it to find all the dependencies. When the file does not exist, it is necessary to specify the information via
With this setup, the program succeeds without relying on the ghc environment file:
Note that if you don't want to specify the hash of the package with |
Now, going back to your original program, there are two extra difficulties. The first one is that you are requesting |
That last part is OK I'm using the 9.6 branch in horizon directly. https://gitlab.horizon-haskell.net/package-sets/horizon-platform/-/blob/master/horizon.dhall#L355 I'll go through your instructions and report back. Thank you very much for writing all that out. |
Ok so by the first method, I still get an error
and the second method also an error
but I found the package.db in a different location
|
See #79 for community-contributed documentation on how to use hint with nix. |
You can use the
You can also use |
The nix thing worked to locate the libraries. I assume with some messing around that will work with cabal build within nix develop, but this gets me a feedback loop now so that's great. However my original polysemy idea doesn't seem to hold up. If I do
Then I get
Not sure where that could be coming from. I'm hoping to get the free monad value across the boundary and interpret it on the other side. Possibly there's another way here. |
I miscounted, there are at least three :) The second difficulty is that the code you are evaluating relies on language extensions. Let's again look at a simpler program:
This is the same situation again: the
|
That's the third difficulty. The type of the code you are evaluating includes an implicit kind parameter. Let's again look at a simpler example: What's the kind of Proxy's type parameter? data Proxy (a :: ?) = Proxy
ex1 = Proxy :: Proxy 'True
ex2 = Proxy :: Proxy "hello" Answer: Proxy has a hidden type parameter! data Proxy {k :: Type} (a :: k) = Proxy
ex1 = Proxy :: Proxy {Bool} 'True
ex2 = Proxy :: Proxy {Symbol} "hello" Now, it just so happens that TypeRep's Show instance chooses to print this hidden type parameter, even though when you write the type in Haskell code, you must not include this hidden type parameter:
Unfortunately, hint relies on TypeRep's Show instance to produce a type signature: {-# LANGUAGE DataKinds #-}
import Data.Proxy
import Language.Haskell.Interpreter (OptionVal((:=)))
import qualified Language.Haskell.Interpreter as Hint
main :: IO ()
main = do
r <- Hint.runInterpreter $ do
Hint.setImports ["Prelude", "Data.Proxy"]
Hint.set [Hint.languageExtensions := [Hint.DataKinds]]
-- original expression:
-- Proxy
-- hint adds a let and a type signature:
-- (let e_1 = Proxy in e_1) :: Proxy Bool 'True
-- ghc adds a name:
-- _compileParsedExpr = (let e_1 = Proxy in e_1) :: Proxy Bool 'True
Hint.interpret "Proxy" (Hint.as :: Proxy 'True)
-- error:
-- Expected kind "Bool -> *", but "Proxy Bool" has kind "*"
-- In an expression type signature: Proxy Bool 'True
-- In the expression: (let e_1 = Proxy in e_1) :: Proxy Bool 'True
-- In an equation for "_compileParsedExpr":
-- _compileParsedExpr = (let e_1 = Proxy in e_1) :: Proxy Bool 'True
print r This hint bug is tracked in #88, and here is the ticket for the upstream bug in TypeRep. |
I should probably explain how the above leads to the mysterious-looking error
That is,
becomes
and then
which is already failing with Oh but wait, TypeRep's Show instance doesn't even wrap
And of course, TypeRep then adds the hidden type parameter for both
|
The workaround is to create a local library exposing a newtype wrapper which does not have a hidden type parameter:
|
(leaving this ticket open to remind me to document all that stuff somewhere...) |
hint-0.9.0.7 now documents the issue with implicit kind parameters in the README. The trick of using ghc environment files or |
Hi. I couldn't find this mentioned anywhere.
But Hint can't pick up the external library
The text was updated successfully, but these errors were encountered: