Jump to Question
| Table of Contents |
|---|
Rholang is not rho calculus, though it's built on top of it. Does the Google doc "rholang spec 0.1" record the current specification?
There's a comment that the latest grammar is here:
https://github.com/rchain/Rholang/blob/master/src/main/bnfc/rholang.cf
Is that up to date? If so, the grammar says
CVar. Chan ::= Var ;
CQuote. Chan ::= "@" Proc3 ;
PDrop. Proc3 ::= "*" Chan ;
PInject. Proc3 ::= "#" Chan ;
In which the only ground terms are identifiers; none of the rest of the Proc structure is referenced. Is the intent eventually to support quoting all rholang processes?
Need to follow up with a meeting to discuss, and finalize the specification as a result of the developer retreat. Medha Parlikar (Unlicensed) to schedule a discussion? Michael Stay (Unlicensed) please confirm.
In the architecture doc, "contract" seems to denote both a term parametric in some names, rather like a class, as well as a particular instance. What is the process by which a contract class gets instantiated to a contract instance? Can there be multiple instantiations? When people say "deploy a contract to a namespace", does that indicate that in addition to specific names there is an additional namespace parameter? Can a contract be deployed to multiple namespaces?
→ Lucius Meredith: Short answer - Yes. When you register a contract, you are associating a process abstraction with a channel. You then feed the actual parameters into the channel and those then get bound to the formals to the abstraction and that is the instantiation process.
→ Former user (Deleted): When you define a contract and send it out, you are creating infinite instances of it. When one instance gets used up, it is immediately reposted. There is only 1 instance at a time When you send something to a name that the contract is bound to, it creates a new one → recursive call example.
→ Lucius Meredith: So when you talk about contracts and namespaces this becomes important. When instantiate the actuals of the contract, those actuals become actual names that inhabit a specific namespace. If the contract is parametric in a bunch of names, then when you supply the actual names, those names live in a specific namespace. So you can deploy a contract definition over a wide variety of namespaces.
Because we have sorts and types of names.
You have type level control over what kind of names can be supplied as actuals to a contract. And you have run time calculation before you ever launch the contract instance, when you have the actuals in hand you can run the calculation over the namespace in which this instance will be running.