I would like your thoughts on some ideas I have about extending flat contracts with additional functionality to fit my needs. Based on my reading, it seems the best way to do that is to define my own struct and set prop:flat-contract property to have it behave as a flat contract.

In my work I use flat-named-contract and flat-contract-with-explanation heavily and would like to reuse as much of their behavior as possible so I was wondering if it’s possible to extract the prop:flat-contract value from contracts returned from the above procedures so in order to copy the value to my custom struct’s prop:flat-contract property? Basically I’d like to delegate the work of constructing contracts. If not, does it make sense to talk about copying an existing contract’s behavior to a new struct, thus converting it into a new flat contract with the same behavior?

In my situation, I would like to define a predicate to recognize instances of a flat named contract I have already defined because I have a function that only accepts those instances in order to create a new contract using them. I can approximate a predicate by using a conjunction of contract?, contract-name and eq? to recognize the flat contract’s known symbolic name. But it’s not foolproof, it’s easy to spoof by passing an unrelated contract that happens to have an identical name. To solve that, it seems I have to set up my own struct and its associated predicate then use that as my contract’s definitive predicate.

Am I even going around this the right way?

@abmclin You could construct a contract the way you want using flat-named-contract, then wrap it with your custom struct and make the various contract functions defer to the wrapped contract.

@lexi.lambda to make sure I understood you correctly, the various contract functions are such as listed under the specifications for prop:flat-contract? I was looking at the implementation for rename-contract which appears to do what I want in terms of extracting the relevant fields from the property using publically available API using get/build-late-neg-projection get/build-val-first-projection and so on

I haven’t gone through all the arguments needed by build-flat-contract-property so don’t know yet if I’ll be able to satisfy all of its requirements but should find out if my experiment is successful