Working Draft PR #6
Conversation
…ken flake.nix one that works. Copied over the template haskell hooks from Cardax.
…tweaked). All basic functionality should be implemented now.
|
Also my, uhm, "extremely elegant" nix hack to get this to work needs fixing. Use |
…ts, implemented bridge for Ledger types w/ TyVar args.
|
Should now work for types with TyVar arguments. I might have missed a Ledger type or two but this is looking pretty complete. Need fix nix / document / setup project tooling / test, but I'm happy with the progress today. |
…ed all the plutus-specific functionality into a new top-level PlutusBridge module.
… .#purescript-bridge
| { | ||
| description = "Generate PureScript data types from Haskell data types"; |
There was a problem hiding this comment.
Tbh I think you'd be better of c/p-ing the Nix setup in Cardax. But also, you can leave Nixification for some other day, we can tackle it together, and just focus on the Haskell side of things.
bladyjoker
left a comment
bladyjoker
left a comment
There was a problem hiding this comment.
This is looking great, I want to get this in order soon, but we need to add some Nix love to this. Let me know if I can join the PR and add some Nix changes...
| # purescript-bridge (Plutus remix) | ||
|
|
There was a problem hiding this comment.
Excellent read! Thanks for doing this!
|
|
||
|
|
There was a problem hiding this comment.
We'll need a chapter on Nix utilities and how to use it in projects.
|
|
||
| packages: ./*.cabal | ||
|
|
||
| --tests: true |
There was a problem hiding this comment.
That was temporary. During the initial nix conversation I needed to make a cabal.project file because... I don't remember, but I'm sure I had to. I wanted to leave that commented as a reminder to myself to, uh, hook up the tests.
| @@ -0,0 +1,19 @@ | |||
| module PlutusBridge ( | |||
There was a problem hiding this comment.
nit; Perhaps Language.PureScript.Bridge.Plutus?
| module PlutusTx.LedgerTypes where | ||
|
|
There was a problem hiding this comment.
nit; consider placing this in Language.PureScript.Bridge.Plutus module if it makes sense to you
| ] | ||
|
|
||
| -- I'm leaving this commented b/c I'm not sure what the module structure for the ledger types should be. | ||
| -- My assumption was that, like Plutarch, we'd just shove everything into it's respective Plutus.V1.Ledger module |
There was a problem hiding this comment.
I agree, however, there's a slight complication in this story. CTL has its own Value type (quite a neat one) that they native support and work with.
What does that mean?
We'll if any of our Datum and Redeemers are using Value, it would make sense to map it to CTL Value and than have toLegacyValue :: CTL.Value -> Plutus.V1.Ledger.Value.Value and ``fromLegacyValue :: Plutus.V1.Ledger.Value.Value -> CTL.Value used in the ToData/FromData instances forCTL.Value`
Does that make sense? Well anyway we need to iron this out.
There was a problem hiding this comment.
That also means that CTL would have to add this repo as a dependency, or we should have a Purescript module that does that conversion. Not sure what makes sense.
There was a problem hiding this comment.
Or Maybe we should have a little Purescript module here that takes care of such conversions?
There was a problem hiding this comment.
CTL should depend on us, I think. I ironed out the compatibility issues in the most recent PR here but I think it's a little confusing that we have to generate all the types except the three (?) that CTL has.
Or maybe it's not that confusing and we can just add a note, I dunno. You're probably in a better position to decide since you've worked on CTL directly.
There was a problem hiding this comment.
Shouldn't CTL export all the ledger types? Like, isn't almost everyone who will use that library going to want those as well?
| typeName ^== haskTypeName | ||
| return $ | ||
| TypeInfo | ||
| { _typePackage = "plutonomicon-cardano-browser-tx" |
There was a problem hiding this comment.
plutunomicon-cardano-transaction-lib
|
@gnumonik should we close this? |
Everything we wanted to move out of Cardax should be here now.
The TH really should be able to accommodate types with type variable arguments, so I'm going to see if I can get that working without too much hassle in a minute.
I didn't port over the
BridgeBuilderstuff yet as I think it might generate duplicate imports due to an interaction with some hacks I made in thePrintermodule.We probably need to think little bit about exactly how we want the API to look, especially w/r/t the Ledger types.