Skip to content
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

GHC 8.6 compatibility #461

Closed
michaelpj opened this issue Jan 8, 2019 · 8 comments
Closed

GHC 8.6 compatibility #461

michaelpj opened this issue Jan 8, 2019 · 8 comments
Assignees
Labels

Comments

@michaelpj
Copy link
Contributor

We'd like to compile with 8.6, especially since this the major version planned to be used for the Shelly release.

However, there is at least one blocker, namely we are affected by https://ghc.haskell.org/trac/ghc/ticket/16104.

@michaelpj michaelpj self-assigned this Jan 8, 2019
@shmish111
Copy link
Contributor

The changes I made to get to this point are in the following patch. The following PR is also open eskimor/servant-subscriber#20

diff --git a/plutus-tx-plugin/src/Language/PlutusTx/Compiler/Expr.hs b/plutus-tx-plugin/src/Language/PlutusTx/Compiler/Expr.hs
index 85d275c1..bfde9fc3 100644
--- a/plutus-tx-plugin/src/Language/PlutusTx/Compiler/Expr.hs
+++ b/plutus-tx-plugin/src/Language/PlutusTx/Compiler/Expr.hs
@@ -69,8 +69,8 @@ This is a pain to recognize.
 convLiteral :: Converting m => GHC.Literal -> m PIRTerm
 convLiteral = \case
     -- TODO: better sizes
-    GHC.MachInt64 i    -> pure $ PIR.Constant () $ PLC.BuiltinInt () haskellIntSize i
-    GHC.MachInt i      -> pure $ PIR.Constant () $ PLC.BuiltinInt () haskellIntSize i
+    (GHC.LitNumber GHC.LitNumInt64 i _) -> pure $ PIR.Constant () $ PLC.BuiltinInt () haskellIntSize i
+    (GHC.LitNumber GHC.LitNumInt i _)   -> pure $ PIR.Constant () $ PLC.BuiltinInt () haskellIntSize i
     GHC.MachStr bs     ->
         -- Convert the bytestring into a core expression representing the list
         -- of characters, then compile that!
@@ -86,13 +86,11 @@ convLiteral = \case
         case maybeEncoded of
             Just t  -> pure $ PIR.embedIntoIR t
             Nothing -> throwPlain $ UnsupportedError "Conversion of character failed"
-    GHC.LitInteger _ _ -> throwPlain $ UnsupportedError "Literal (unbounded) integer"
-    GHC.MachWord _     -> throwPlain $ UnsupportedError "Literal word"
-    GHC.MachWord64 _   -> throwPlain $ UnsupportedError "Literal word64"
     GHC.MachFloat _    -> throwPlain $ UnsupportedError "Literal float"
     GHC.MachDouble _   -> throwPlain $ UnsupportedError "Literal double"
     GHC.MachLabel {}   -> throwPlain $ UnsupportedError "Literal label"
     GHC.MachNullAddr   -> throwPlain $ UnsupportedError "Literal null"
+    GHC.LitNumber _ _ _   -> throwPlain $ UnsupportedError "Literal null"

 isPrimitiveWrapper :: GHC.Id -> Bool
 isPrimitiveWrapper i = case GHC.idDetails i of
diff --git a/plutus-tx-plugin/src/Language/PlutusTx/Compiler/Kind.hs b/plutus-tx-plugin/src/Language/PlutusTx/Compiler/Kind.hs
index ca653672..b94fd988 100644
--- a/plutus-tx-plugin/src/Language/PlutusTx/Compiler/Kind.hs
+++ b/plutus-tx-plugin/src/Language/PlutusTx/Compiler/Kind.hs
@@ -17,6 +17,6 @@ import qualified Language.PlutusCore              as PLC
 convKind :: Converting m => GHC.Kind -> m (PLC.Kind ())
 convKind k = withContextM (sdToTxt $ "Converting kind:" GHC.<+> GHC.ppr k) $ case k of
     -- this is a bit weird because GHC uses 'Type' to represent kinds, so '* -> *' is a 'TyFun'
-    (GHC.isStarKind -> True)              -> pure $ PLC.Type ()
+    (GHC.isLiftedTypeKind -> True)              -> pure $ PLC.Type ()
     (GHC.splitFunTy_maybe -> Just (i, o)) -> PLC.KindArrow () <$> convKind i <*> convKind o
     _                                     -> throwSd UnsupportedError $ "Kind:" GHC.<+> GHC.ppr k
diff --git a/stack.yaml b/stack.yaml
index 1b6b3ca8..ca7e3f74 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -1,4 +1,4 @@
-resolver: lts-12.14
+resolver: lts-13.2

 packages:
 - language-plutus-core
@@ -24,8 +24,8 @@ packages:
   extra-dep: true

 - location:
-    git: https://github.com/smobs/servant-subscriber.git
-    commit: 0354e99f5e1d244d5ec01f78e7e7439478b1d1d3
+    git: https://github.com/shmish111/servant-subscriber.git
+    commit: e7fc0d049b85b45073d818541c6a7678c8222ce8
   extra-dep: true

 extra-deps:
@@ -35,6 +35,8 @@ extra-deps:
 - hint-0.9.0
 - exceptions-0.10.0
 - purescript-bridge-0.13.0.0
+- algebraic-graphs-0.2
+- composition-prelude-2.0.2.1
 flags:
   language-plutus-core:
     development: true
@@ -50,4 +52,4 @@ flags:
     development: true
 extra-package-dbs: []
 nix:
-  packages: [gmp, openssl]
+  packages: [zlib, gmp, openssl]
diff --git a/wallet-api/src/Ledger/Types.hs b/wallet-api/src/Ledger/Types.hs
index a7d84c68..23909f5b 100644
--- a/wallet-api/src/Ledger/Types.hs
+++ b/wallet-api/src/Ledger/Types.hs
@@ -99,6 +99,9 @@ module Ledger.Types(
     inSignature
     ) where

+import qualified Language.PlutusTx.Builtins
+import qualified GHC.IO.Unsafe
+import qualified Data.ByteString.Unsafe
 import qualified Codec.CBOR.Write                         as Write
 import           Codec.Serialise                          (deserialise, deserialiseOrFail, serialise)
 import           Codec.Serialise.Class                    (Serialise, decode, encode)

@michaelpj
Copy link
Contributor Author

@angerman is going to bring up the GHC ticket at the next GHC HQ call.

@vmchale
Copy link
Contributor

vmchale commented Jan 12, 2019

For my englightenment, is the plan then to jump to GHC 8.8, or rather to use some kind of GHC 8.6.4?

@angerman
Copy link
Contributor

@vmchale is there a reason you'd like to skip 8.6? As 8.8 hasn't been released yet, that would be a bit aggressive, no?

@vmchale
Copy link
Contributor

vmchale commented Jan 13, 2019

Oh, no, I was just curious. I have no interest in skipping 8.6 if it is detrimental to development :)

@angerman
Copy link
Contributor

@vmchale so your question is more as to why not to stick with 8.4?

@michaelpj
Copy link
Contributor Author

Well, hopefully this will get fixed for 8.6.4 rather than 8.8. And remember we want to use 8.6 because it's what the new Cardano is planning to use for their release.

@michaelpj
Copy link
Contributor Author

Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants