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

Make the table of pretty-printing custom names mutable #440

Open
florentc opened this issue Jul 19, 2024 · 2 comments
Open

Make the table of pretty-printing custom names mutable #440

florentc opened this issue Jul 19, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@florentc
Copy link
Member

It is possible to define custom human-readable names for any hash (scripts and pubkeys) in the pcOptHashNames options of the pretty printing options PrettyCookedOpts.

This is usually set statically once before running a trace.

However there are cases when this approach has limits.

For instance, given a parameterized script whose parameter will be some element from the chain (a spent UTxO for example when minting nfts), we don't have the information beforehand to add an entry to the table. Hence, there can't be any human readable name for hashes corresponding to parameterized scripts.

It would be a nice quality of life feature if these names could be updated in the course of a trace in the block chain state (where and how should be investigated).

At the end of execution, the resulting value of the custom names table would be used for pretty printing.

@florentc florentc added the enhancement New feature or request label Jul 19, 2024
@mmontin
Copy link
Collaborator

mmontin commented Jul 24, 2024

There is another improvement of this naming feature that could be coupled to this issue:

At the moment, we use the option pcOptHashNames to store a map of names to replace associated hashes in the pretty printer. This is very convenient. However, we also have a default map of names defaultHashNames which is problematic because it is overridden very easily when the user specifies new hashes. The cheatsheet does mention how to not override it, but still it is inconvenient. What we could do instead is have this default list hard coded in the pretty printer. When printing a hash, we would proceed as follows:

  • look up for it the provided map
  • look up for it in the default hardcoded map when absent from the map above
  • print the hash if absent from both

This way we keep the current behavior that you can override the default, but it is no longer required to manually mention the default names in the option (and it has to be at the end) when specifying new names.

This changes would come alongside a new option pcOptDisableDefaultName which would be set to False by default and which would disable to search in the default name list when set to True, just in case user really don't want to see those default names, and see hashes instead for some reason.

@mmontin
Copy link
Collaborator

mmontin commented Jul 24, 2024

About the first idea, I believe it's a good one. A few observations:

  • we should make sure not to add too many 'auxiliary' features our mockchain
  • maybe there would be a way to centralize 'auxiliary' features such a logging or this in another type class
  • we need to make sure that the monad stack allows to retrieve the list of name even in a case of failure

A possible implementation for this could be:

addHashable :: (ToHash a) => String -> a -> m a

and it could be used as follows:

myValidator <- addHashable "myValidator" $ myValidatorParameterized dynamicParam

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

No branches or pull requests

2 participants