Expand and improve inter-contract comunication

[steinerkelvin]

• IO to get state of another contract #204
• IO to get signer (first subj) #232
• allow multiple U120-tuples as arguments #230

---

• contracts that can run statements?
  • e.g. contracts can own namespaces and deploy code inside them

---

Some other possibilities:

• monotype buffer interface
  • which KHVM structure could be used?
    • just a plain U120 cons-list
    • U120-tuple cons-list
    • Braun trees?
    • something else?
• marked/trusted contracts allowed to pass raw terms / "trusted call"
  • how?
  • complexity seems not worth it

Related to #35 and #116.
cc @o-santi

[o-santi]

What about adding a way to pattern match an specific type?
For example, adding a # to the variable in the following rule:

(Counter {Add #n}) =
  ask x = (Take);
  ask (Save (+ x n))
  (Done #0)

would make it so that only numbers could be pattern matched. This would add a little bit of overhead to the information stored about variables, but it would make for a more expressive inter-contract comunication (as there's no fixed way to send information).

Another place where computation could get stuck is when expecting lambdas:

fun (MutState f) {
  ask x = (Take);
  ask (Save (f x));
  (Done #0)
} with {
  #0
}

and for that, we could also add the @ sign in front of f, in order to match only lambda terms.

If we restrict inter-contract communication to, say, only U120-cons list, how would contracts pass lambdas to each other? Isn't there value to it? Wouldn't it be more expressive if we didn't limit which kinds of terms we pass to one another?

[o-santi]

Of course, if the lambda term has a different arity than the contract expects, it could also get stuck.

fun (LambdaTwoArgs f) {
  (LambdaTwoArgs f) =
    ask state = (Take);
    ask (Save ((f state) #2));
    (Done #0)
} with { 
  #0   
}
// would get stuck when called with
(LambdaTwoArgs @x x)

If the arguments to this lambda term are not what you expect (ie. a number instead of a constructor) it could also get stuck.

fun (LambdaSum f) {
  (LambdaSum f) =
    ask (Save (f {RandomCtr}));
    (Done #0)
} with { 
  #0   
}
// would get stuck when called with
(LambdaSum @x (+ x #2))

Probably the smallest type-checker that would be useful is somekind of simply-typed-lambda type checker + ADT's, because constructors could have a specific type, and even if a function expects that an argument is a constructor, it may not be in the possible constructors that it matches. For that, we would need algebraic sum types.

And of course, I know that it would add overhead to all the language. Maybe before publishing a statement (be it a run or a fun) it would need to first pass the type checker? This way only type-sane terms would be able to be published to the network, and almost no overhead would incur in computations inside the chain (and I think it could cover all of the obvious cases).

cc @VictorTaelin

[steinerkelvin]

Earlier iterations of the design — last year, even before the HVM — had a simple, inexpensive type system that solved much of it because it was a simple system with basically ADTs. But a big point of the new design with the HVM is we can now do very high-level stuff with a clear cost model, and (a) there are no clear answers to what type of system would be the Right One™; (b) even the Right One would also add a lot of complexity to the system.

P.S. I see you have some actual simple type-checking in mind. As I'm not knowledgeable of type systems, I'll leave that discussion for you and Victor while I focus on finding other ways.