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

Update PrettyCooked #426

Open
mmontin opened this issue Jun 28, 2024 · 2 comments
Open

Update PrettyCooked #426

mmontin opened this issue Jun 28, 2024 · 2 comments

Comments

@mmontin
Copy link
Collaborator

mmontin commented Jun 28, 2024

At the moment, our PrettyCooked features suffers from small inaccuracies:

  • module Pretty.Cooked is far too long
  • we sometimes use PP.pretty instead of prettyCookedOpts
  • some PrettyCooked instances are located in Pretty.Class, some others in Pretty.Cooked and the reason for this separation is unclear.
  • some PrettyCooked instances are actually written as instances, while others are functions named prettyXXX but are basically instances. This can lead to repeated code if one does not realize an instance is here but is not actually written as such.
  • PrettyCooked has it own hashable type class which could maybe be factored with toScriptHash to some extent (see Homogenize Hashing #424)

In addition, there could be some improvements:

  • code can be factored (for example for redeemers)
  • we could provide some automation to deduce PrettyCooked instances
@mmontin
Copy link
Collaborator Author

mmontin commented Jul 1, 2024

The factoring for redeemers is being performed in PR #428

@mmontin
Copy link
Collaborator Author

mmontin commented Jul 9, 2024

what was the thought process behind centralizing all pretty cooked instances in dedicated modules? I find it very prone to circular dependencies issues.

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

No branches or pull requests

1 participant