-
Notifications
You must be signed in to change notification settings - Fork 64
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
Reorganize module hierarchy #738
Conversation
@@ -0,0 +1,810 @@ | |||
{-# LANGUAGE FlexibleInstances #-} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is quite massive. More so than I thought, would it be better to make Plutarch.Builtins.XYZ
modules instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree.
Will also resolve #735 |
Notes: this is closed because of nasty conflict |
This is the first attempt to try and make some sense of the module hierarchy. The overall goals were:
Plutarch.Prelude
and get everything they needPlutarch.Prelude
, only things in thePlutarch.Internal.*
namespaceplutarch-ledger-api
andplutarch-testlib
should rely minimally on imports fromPlutarch.Internal.*
Additionally, there were a couple of changes:
pbuiltinMyBuiltinName
inPlutarch.Internal.Builtin
, allowing them to be called without having to wonder what their signatures are.Plutarch.*
has been significantly emptied.Plutarch.Internal.Builtin
contains (most of) the types that we have to have because they're mandated by Plutus.This is not the final outcome, I just wanted to get something reviewed and merged, or the diffs would get too huge.