WIP: Hakuzaru fixes and tweaks #33

2026-06-15T11:38:46+09:00

spivee commented

2026-06-15 11:38:46 +09:00

There is a fair bit going on in this PR; it is worth looking at each commit individually, rather than the diff of the entire branch.

I'm particularly interested in discussing the last commit, because

I don't really like the name parse_tx_info
I don't really like the name read_contract_getter either
I don't really like the name 'deploy' for the atom that can be passed to parse_tx_info for the "get the contract ID that this transaction took place on, knowing that in the case of init() that contract ID will be the ID of the contract that was just created" path
I am finding it hard to create errors in contract initialization, to see what the error format looks like, in order to handle those errors gracefully in parse_tx_info, so right now they are not handled
having the "convert a list of arguments from Erlang to FATE" function live alongside the single arg version, in hz_aaci, and the "convert a list of arguments from Sophia to FATE" live totally separate from the single arg version, in hz instead of hz_sophia, seems like something that should be cleaned up at some point
decode_bytearray_fate is trying to handle cases that parse_tx_info should have handled already, so I should clean that up
once I know what to call the two functions I made public, they should also have types and documentation!

but apart from that, I am quite happy with the functionality and fixes of these commits.

There is a fair bit going on in this PR; it is worth looking at each commit individually, rather than the diff of the entire branch. I'm particularly interested in discussing the last commit, because - I don't really like the name parse_tx_info - I don't really like the name read_contract_getter either - I don't really like the name 'deploy' for the atom that can be passed to parse_tx_info for the "get the contract ID that this transaction took place on, knowing that in the case of init() that contract ID will be the ID of the contract that was just created" path - I am finding it hard to create errors in contract initialization, to see what the error format looks like, in order to handle those errors gracefully in parse_tx_info, so right now they are not handled - having the "convert a list of arguments from Erlang to FATE" function live alongside the single arg version, in hz_aaci, and the "convert a list of arguments from Sophia to FATE" live totally separate from the single arg version, in hz instead of hz_sophia, seems like something that should be cleaned up at some point - decode_bytearray_fate is trying to handle cases that parse_tx_info should have handled already, so I should clean that up - once I know what to call the two functions I made public, they should also have types and documentation! but apart from that, I am quite happy with the functionality and fixes of these commits.

spivee added 4 commits 2026-06-15 11:38:47 +09:00

fix bytes coerce logic ea3a5453f2

Add special anonymous variant syntax d323fb0f52

This is outside of the scope of the sophia parser, but is a simple generalization to
'sophia terms' to make them able to represent any FATE term anonymously.

We also parse these anonymous variant expressions without type info, since it is convenient
for users to copy the output of one call into another call.

Anonymous parsing of None and Some was also added, since new users would be shocked if this
doesn't work, and advanced users will greatly appreciate that it does. The resulting FATE
terms are still rendered as variant([0, 1], ...), since user defined types can also have [0, 1]
as their arity list, and since automation and tooling programmers hate special case exceptions like that.

Anonymous parsing of other Chain and AENS terms are not added, since anonymous variants already cover those types,
so very little is gained by hard-coding such complex types into the term parser. Complex, version-specific compiler
types are already supported by hakuzaru, in the form of the ACI/AACI; parsing without AACI, on the other hand, is
intended to support language-agnostic communication using the primitives of FATE, and in general, variants
in FATE are anonymous.

unwrap fate_to_erlang results 6daad4974c

fate_to_erlang can only really fail at runtime if the wrong AACI is
provided, in which case the details of how failure occured are not
helpful, or recoverable. Anything else will be so broken that dialyzer
will catch it, or is a bug in hakuzaru, that we want to know about.

add parse_tx_info and read_contract_getter 4302ae002c

parse_tx_info takes the output of tx_info OR dry_run and strips it down to a cb_ encoded binary,
and then passes that cb_ encoded binary to decode_bytearray, using the Format specified.

read_contract_getter combines contract_call and dry_run, but automatically identifies the owner of the contract,
and uses that as the caller, and gives the caller a huge amount of gajus for the purpose of the dry run, so that
the call always succeeds. This operation should be available in the node itself, rather than requiring us to do
this huge back and forth for something as simple as reading the contents of the blockchain, but at least we can
abstract over this in the tooling, and save the user from having to think about these steps.

spivee marked the pull request as work in progress 2026-06-15 11:40:08 +09:00

spivee requested review from zxq9 2026-06-15 11:40:15 +09:00

spivee added the enhancement help wanted labels 2026-06-15 11:41:11 +09:00

spivee added 1 commit 2026-06-15 13:53:19 +09:00

Fix read_contract_getter/4 cf66548443

This was meant to be a placeholder that I would catch and fix, but my test case never hit it! Whoops.

This pull request is marked as a work in progress.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin spivee/fixes:spivee/fixes

git checkout spivee/fixes

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/hakuzaru#33