octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #58953] Error with 'end' in index expression w


From: Fernando
Subject: [Octave-bug-tracker] [bug #58953] Error with 'end' in index expression with nested function calls
Date: Tue, 22 Sep 2020 20:49:11 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

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

I think the issue is about the Octave implementation, and whether the proposed
change (calling tree_evaluator::evaluate_end_expression in
tree_identifier::evaluate_n when the identifier is "end") is correct in all
situations.

I understand your concerns, jwe.

As you know, the reason for calling tree_evaluator::evaluate_end_expression
directly, instead of doing it indirectly by calling the builtin "end"
function, is because "end" might need to evaluate an expresion like obj.X,
where obj is an object from a class that redefines the subsref method. In that
case, Octave needs to know whether that happens in the context of a method
from the class of obj or not, to call the suitable subsref (as pointed out by
Guillaume). In order to know the class context, octave obtains the class of
the current function, but that function should not be the "end" function, but
the function where the "end" expression happens.

Is that correct in all cases? I think it is, but I am not 100% sure. At the
point where tree_evaluator::evaluate_end_expression is called in
tree_identifier::evaluate_n, the unpatched code would call the function "end"
without arguments. If that function has not been redefined, Octave would call
octave_builtin::execute, which would call the builtin "end", which would call
tree_evaluator::evaluate_end_expression. Ok, octave_builtin::execute also sets
up the profiler and does some processing with the returned values. I don't
know if that is important. On the other hand, the "end" function could have
been redefined, but I don't think it is wise to redefine the general "end"
function. I tried it in Matlab and it behaves unpredictably.

Anyway, there is another possibility that you might feel more comfortable
with. It would be something like (in tree_identifier::evaluate_n):


if (name () == "end")
  obtain the arguments to be passed to the end function
else
  args = empty list

retval = fcn->call (tw, nargout,args);



    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Mensaje enviado vía Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]