[RFC] Revise discussion of 'input' treatment.

Incorporate suggestions from Eric and Mazdak on this.
This commit is contained in:
Alessandro Coglio 2021-09-21 09:49:36 -07:00
parent 1fc9814421
commit e08d2522f1

View File

@ -205,10 +205,11 @@ or whether it should be explicitly passed to the entry point functions and to th
The first approach is more concise, while the second approach is more explicit. The first approach is more concise, while the second approach is more explicit.
Note that, in the second approach, we may want to enforce certain restrictions on the use of `input`, Note that, in the second approach, we may want to enforce certain restrictions on the use of `input`,
e.g. we may not want to allow a call `f(input, input)` even if the parameters of `f` both have the same circuit type as `input`. e.g. we may not want to allow a call `f(input, input)` even if the parameters of `f` both have the same circuit type as `input`.
That is, even if we make the passing of `input` explicit, There is nothing inherently wrong with `f(input, input)`, i.e. with handling `input` by value,
there is still something special about it; except that perhaps `input` is a relatively large structure,
in essence, it still needs to be treated essentially like a global variable, and duplicating it generates a (relatively) large number of R1CS constraints.
i.e. in a single-threaded way. Another idea is to pass `input` by (immutable) reference behind the scenes,
analogously to how we pass `self` by mutable reference to functions with `mut self`.
The treatment of output records is less clear at this point. The treatment of output records is less clear at this point.
As mentioned above, experimentation suggests that currently the output values of `main` are serialized into new records. As mentioned above, experimentation suggests that currently the output values of `main` are serialized into new records.