Contract Implementation Thoughts
Contract programming would require something akin to continuations, which are a good way of approaching persistent program state. We are talking here about programs that sit and hold a state for days or months or even years while they wait for participants to fulfill each piece of the contract. Take, for example, several of the methods I called in the pseudo code:
comfirm(client, designer, self) verify(client, deliverables)
As with the Amazon’s mechanical turk API, certain simple calls actually abstract extremely complex transactions and interactions. The confirm method, for example, requires both parties to examine and agree to participate in the contract. The verify method similarly requires a person to examine and verify the created document.
By providing this sort of functionality as atomic building blocks, users could easily construct their own contracts. A market for contracts and contract programmers could even arise.
rss