assgignements of the form [n, x(n)] = ...

[John W. Eaton]

Matlab allows

  [n, x(n)] = deal (1, 2)

but Octave does not.  In Octave, the LHS is evaluated first to
determine the value of NARGOUT for the evaluation of the RHS.  In the
old days, I think we simply counted the elements on the LHS and looped
over them in turn, so the above expression would succeed, but now we
can't do that because we need to handle things like

  x = cell (1, 2);
  [x{:}] = deal (1, 2)

so we must evaluate (at least partially) the elements of the LHS to
determine the value of NARGOUT.  But when we changed the evaluator to
handle this case, we apparently went too far.  So we need to do
something slightly different.

The assignment is handled in the function

  tree_multi_assignment::rvalue (int)

in src/pt-assign.cc, which calls

  tree_argument_list::lvalue_list (void)

in src/pt-arg-list.cc to convert the LHS of the assignment to a list
of octave_lvalue objects.  It's at this point that the evaluation of
each element occurs so we can determine the value of NARGOUT.  Since
only '{}' and '.' indices can produce comma-separated lists that will
count as more than one element for NARGOUT, I suppose the fix is to
skip the evaluation if the index is '()' and allow the list of
octave_lvalue objects to contain unevaluated elements.  Then for
expressions like the first one above, we will be able to evaluate N
before X(N).  Note that it is still OK for

  [n, x{1:n}] = deal (...)

to fail if N is not previously defined, as there is no way to compute
NARGOUT without knowing N, and NARGOUT must be known before the RHS is
evaluated.

Also, I think this means that '()' must always appear as the lasst
index in expressions like this.  Octave does not currently enforce
that restriction, but I think Matlab does.  But we could still allow
it in other contexts, as people seem to like to be able to do things
like

  svd(x)(1)

or

  size(x)(1)

(even though they should be using size(x,1) for the latter).

I have not attempted to implement this change, but wanted to make a
note of it.

As this is not a regression from 3.0 and the fix is likely to require
some significant changes, I don't think we should try to fix it for
any 3.2.x version.

jwe