[Octave-bug-tracker] [bug #58953] Error with 'end' in index expression with nested function calls

[John W. Eaton]

Follow-up Comment #34, bug #58953 (project octave):

OK, thanks.  In Octave, we try to do the evaluation in advance, but that
causes a lot of trouble and I see no reasonable way to distinguish


obj.data (variable (end))  ## end applies to variable
obj.data (function (end))  ## end applies to obj.data


But if we instead just cache the info for the expression we have processed so
far (without evaluating it) and make that available to the "end" function,
then I think it all falls out naturally in a compatible way.  So we would
store the parse tree expression info for "obj.data", then when needing to
compute the argument list for that, we can evaluate it, calling subsref if
needed.  If the argument list also contains an expression, we perform this job
again, recursively, so we just push another expression on the stack of cached
info for "end" and pop it off when the argument list evaluation is complete. 
But at that point, we are in the natural place to determine whether the
indexed object is a variable (push new expression info) or a function (don't
push).

I think we would also no longer have to store info about whether the argument
list contains a "magic end" token, we just process it when it appears.

I'll see whether I can turn that into some code.  The same approach should
also apply to bug #55856.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58953>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/