[m-rev.] for post-commit review: clarify state var documentation

[Julien Fischer]

Hi Zoltan,

On Sat, 18 Sep 2021, Zoltan Somogyi wrote:

> diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi
> index c563b0855..f81b1a71e 100644
> --- a/doc/reference_manual.texi
> +++ b/doc/reference_manual.texi


> @@ -1256,18 +1270,35 @@ is locally scoped to the lambda expression
>  and the lambda expression may refer to
>  the next version of a local state variable.
> 
> -There are three restrictions concerning state variables in lambdas:
> -first, @samp{!@var{X}} is not a legitimate function result,
> -since it stands for two arguments, rather than one;
> -second, @samp{!@var{X}} may not appear as a parameter term
> -in the head of a lambda,
> -since there is no syntax
> -for specifying the modes of the two implied parameters;
> -third, @samp{!@var{X}} may not appear as an argument in a function application
> +There are two restrictions concerning state variables in functions,
> +whether they are defined by clauses or lambda expressions.
> + at itemize
> + at item
> + at samp{!@var{X}} is not a legitimate function result,
> +since it stands for two arguments, rather than one.
> + at item
> + at samp{!@var{X}} may not appear as an argument in a function application
>  since this would not make sense
>  given the usual interpretation of state variables and functions.
>  (The default mode of functions is that all arguments are input,
>  while in the overwhelming majority of cases, @samp{!:@var{X}} is output.)
> + at end itemize
> +
> +Within each clause, a transformation converts state variables
> +into sequences of ordinary logic variables.

I suspect the use of the term "logic variables" here is likely to cause
I suggest: s/ordinary logic variables/ordinary variables/.

The diff looks fine otherwise.

Julien.