State of input arguments after PANIC (answer Scott's question about guarantees in Section 2.4 on Error Models)

[tgmattso]

Execution errors (listed in Table~\ref{Tab:GrBInfoValues}(c)) indicate that 
something went wrong during the execution
of a legal GraphBLAS method invocation.  Their occurrence may depend on
specifics of the execution environment and data values being manipulated.
This does not mean that execution errors are the fault of the GraphBLAS
implementation.  For example, a memory leak could arise from an error in
an application's source code (a ``program error''), but it may manifest
itself in different points of a program's execution (or not at all)
depending on the platform, problem size, or what else is running at
that time.  Index out-of-bounds errors, for example, always indicate a
program error.

If a GraphBLAS method returns with any execution error other than 
{\sf GrB\_PANIC}, it is guaranteed that the state of any argument used as 
input-only is unmodified.  Output arguments may be left in an invalid state, 
and their use downstream in the program flow may cause additional errors.  If a 
GraphBLAS method returns with a {\sf GrB\_PANIC} execution error, no guarantees 
can be made about the state of any program data. 
\scott{Is this statement true of input arguments?}

I think the statement in question is true. We need to look it over and make a final call

[DrTimothyAldenDavis]

The statement cannot be true of inputs. Inputs may also be left modified if an execution error occurs.

Suppose an input matrix A for GrB_mxm has pending work, and I must complete (wait on) the work to finish before computing C=A*B. While computing A, I run out of memory, but I've already partially modified A to compute its new value. I cannot return to the unmodified value of A, so I just clear it of all entries in this case.

So I would state instead:

If a GraphBLAS method returns with any execution error, then any input or output arguments may be left in an invalid state, and their use downstream in the program flow may cause additional errors.

[tgmattso]

Yes, I mean line 789. I actually agree with Tim on this one. If there is an execution error, all bets are off

If we don't do this, then the implementor has to do operations into separate storage and copy into final destinations only after the operations are done and gauranteed to be free of errors

[tgmattso]

We are going to defer any changes pertaining to this issue. Basically, the text as is covers what we need. We agree that we can be a bit more relaxed than the current text allows, but making the needed changes for such relaxation is more than we have time for now. We'll pick this up for 2.1