kadena-io / pact

The Pact Smart Contract Language
https://docs.kadena.io/build/pact
BSD 3-Clause "New" or "Revised" License
583 stars 101 forks source link

Better metadata in `describe-module` #1017

Open sirlensalot opened 2 years ago

sirlensalot commented 2 years ago

Currently describe-module returns the following, e.g. for (describe-module 'coin):

{
  "hash": "rE7DU8jlQL9x_MPYuniZJf5ICBTAEHAIFQCB4blofP4",
  "blessed": [
    "ut_J_ZNkoyaPUEJhiwVeWnkSQn9JT9sQCWKdjjVVrWo",
    "BjZW0T2ac6qE_I5X8GE4fal6tTqjhLTC7my0ytQSxLU",
    "1os_sLAUYvBzspn5jjawtRpJWiH1WPfhyNraeVvSIwU"
  ],
  "keyset": "Governance {_gGovernance = Right (Def {_dDefName = ...",
  "interfaces": [
    "fungible-xchain-v1",
    "fungible-v2"
  ],
  "name": "coin",
  "code": "(module coin ..."
}

Improvements include:

Fix keyset output (or change to governance)

The current output is useless. Suggest something like { "type": "defcap|keyset", "value": ... }

Add a "members" field

This is a list of all declared members. Suggest following for member schema:

  { "name": "transfer"
  , "type": "defun|defcap|defpact|defconst|defschema|deftable"
  , "definition": { ... } 
  }
alber70g commented 1 year ago

When I was cleaning up the kadena-community/kadena.js issues, I came across this comment

A few thoughts:

An AST from the contract would benefit tool makers. Could be a property in the current describe-module response. Could be instead of the "members" field that you mention, but a members field would serve this purpose too.

An AST would also allow end users to traverse the tree and find which caps are necessary for each defun. If that's something we can offer from describe-module directly, that would be even easier.

For @kadena/client we'd like to be able to also have the dependencies for each contract. Mainly for the defcaps to know what should be added as a cap to a transaction in the transactionbuilder.