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

Composition of progams #108

Open
uncomputable opened this issue Jun 5, 2023 · 1 comment
Open

Composition of progams #108

uncomputable opened this issue Jun 5, 2023 · 1 comment

Comments

@uncomputable
Copy link
Collaborator

We should implement the composition of two finalized programs (1 → 1). How should this be done?

Approach 1: Unfinalize, combine, refinalize

Trivially correct. The type of witness nodes may change if there were any free variables (that were mapped to unit) in either program. This could confuse users.

Approach 2: Unify finalized programs

Potentially more efficient. Should work if the type pointers of both programs don't overlap (they come from different Contexts)? What are the conditions that this works? Do we refuse to unify if these conditions are not satisfied?

What happens if unification fails? AFAIU, the current algorithm tries to greedily unify until it gets stuck. Any bindings that are created in the process stay. Unification for composition should be atomic.

@apoelstra
Copy link
Collaborator

I think we should only allow composition of unfinalized programs CommitNodes .... I think once you have a RedeemNode this should basically be an immutable object.

If we support composing redeemnodes we also need to think about what to do with witnesses.

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

2 participants